From andrew at openjdk.java.net  Mon May  2 01:20:49 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 2 May 2022 01:20:49 GMT
Subject: [jdk8u-dev] Integrated: Merge jdk8u:master
Message-ID: <13jUs_2e0oyQY6DM-QqpQyrwghlBWtsGKyFqL0hYlXA=.569a5687-9b5a-4e93-8409-05111ad1ff29@github.com>

Sync 8u-dev with 8u, prior to 8u342-b01 promotion

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

Commit messages:
 - Merge jdk8u:master
 - 8285445: cannot open file "NUL:"
 - 8284772: 8u GHA: Use GCC Major Version Dependencies Only
 - Merge
 - 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream
 - 8261107: ArrayIndexOutOfBoundsException in the ICC_Profile.getInstance(InputStream)
 - 8253424: Add support for running pre-submit testing using GitHub Actions
 - 8281814: Debuginfo.diz contains redundant build path after backport JDK-8025936
 - 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale
 - 8274751: Drag And Drop hangs on Windows
 - ... and 11 more: https://git.openjdk.java.net/jdk8u-dev/compare/ee82a7d9...2f4809ff

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

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/51/files
  Stats: 7073 lines in 74 files changed: 5877 ins; 927 del; 269 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/51.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/51/head:pull/51

PR: https://git.openjdk.java.net/jdk8u-dev/pull/51

From andrew at openjdk.java.net  Mon May  2 01:20:49 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 2 May 2022 01:20:49 GMT
Subject: [jdk8u-dev] Integrated: Merge jdk8u:master
In-Reply-To: <13jUs_2e0oyQY6DM-QqpQyrwghlBWtsGKyFqL0hYlXA=.569a5687-9b5a-4e93-8409-05111ad1ff29@github.com>
References: <13jUs_2e0oyQY6DM-QqpQyrwghlBWtsGKyFqL0hYlXA=.569a5687-9b5a-4e93-8409-05111ad1ff29@github.com>
Message-ID: <jwp1WvbfrxA2DOD9xBB6RhLfkdFs1jleONkIDjsHzkw=.68753430-9f5c-4d57-8dd6-c170ba5bd176@github.com>

On Mon, 2 May 2022 01:11:09 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Sync 8u-dev with 8u, prior to 8u342-b01 promotion

This pull request has now been integrated.

Changeset: 1bc3be25
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/1bc3be259a1367d0b671ee0e8a85e314d7d05637
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

Merge

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/51

From andrew at openjdk.java.net  Mon May  2 01:26:46 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 2 May 2022 01:26:46 GMT
Subject: [jdk8u-dev] RFR: 8285802: AArch64: Consistently handle offsets in
 MacroAssembler as 64-bit quantities
In-Reply-To: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>
References: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>
Message-ID: <dlA5JyN_3Zdl0FQZSCEetvx_3giKNY1esCMHnkDk0SQ=.a1dfa10e-5f92-4f98-a380-2777c43f548a@github.com>

On Fri, 29 Apr 2022 17:40:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This is a backport of [8285802](https://github.com/openjdk/jdk/commit/df4d5cf5f53c1451487e6301d31c196fac029f7a) from the openjdk/jdk repository. It's almost clean, but upstream mainline has a few
> cleanups of integer type handling, so there is some additional backporting risk.

@theRealAph please change the PR title to "Backport df4d5cf5f53c1451487e6301d31c196fac029f7a" so SKARA correctly picks this up as a backport. See https://wiki.openjdk.java.net/display/SKARA/Backports  Thanks.

Also it looks like you need to enable GitHub Actions on this repository so the test builds run. See https://wiki.openjdk.java.net/display/SKARA/Testing

Not too big a deal on this one though, as there is not yet any AArch64 testing.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/50

From aph at openjdk.java.net  Mon May  2 09:12:45 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 2 May 2022 09:12:45 GMT
Subject: [jdk8u-dev] RFR: 8285802: AArch64: Consistently handle offsets in
 MacroAssembler as 64-bit quantities
In-Reply-To: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>
References: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>
Message-ID: <VCRzjYfm13UtDEi_sMpZ7wlbOWUy7lhxQ2msR8jFndw=.2a0460bd-1a9b-4590-bf1d-7ff3944f2ba5@github.com>

On Fri, 29 Apr 2022 17:40:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This is a backport of [8285802](https://github.com/openjdk/jdk/commit/df4d5cf5f53c1451487e6301d31c196fac029f7a) from the openjdk/jdk repository. It's almost clean, but upstream mainline has a few
> cleanups of integer type handling, so there is some additional backporting risk.

I'm going to have to do some more work on this one.

Is there something we can do to make testing work automatically?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/50

From zgu at openjdk.java.net  Mon May  2 12:41:12 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 2 May 2022 12:41:12 GMT
Subject: [jdk8u-dev] RFR: 8284620: CodeBuffer may leak _overflow_arena
Message-ID: <0_0B3Wbda4gVbRm3uG08U7LME-LsSx6BR8UCLcc_1R0=.aaa95d24-1947-409d-84a0-2361d507ef7d@github.com>

I would like to backport this patch to 8u for fixing a memory leak.

The original patch does not apply cleanly due to context difference. However, the patch is small, easily resolved manually.

Test:

- [x]  hotspot_compiler

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

Commit messages:
 - Backport 4d45c3ebc493bb2c85dab84b97840c8ba093ab1f

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/52

From tianshuang.me at icloud.com  Wed May  4 14:23:50 2022
From: tianshuang.me at icloud.com (tianshuang)
Date: Wed, 4 May 2022 22:23:50 +0800
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
Message-ID: <6B8F294E-C29D-40C2-B21A-B5C2C814AFC6@icloud.com>

Hi,

I want to backport [JDK-8214427](https://bugs.openjdk.java.net/browse/JDK-8214427 <https://bugs.openjdk.java.net/browse/JDK-8214427>), it fixes the bug that MAX_RESIZERS in ConcurrentHashMap.addCount() does not take effect, original patch does not apply cleanly to 8u.

Original patch: https://github.com/openjdk/jdk/commit/8846159987f902bb6e2b966eb4656da4b6d9469d <https://github.com/openjdk/jdk/commit/8846159987f902bb6e2b966eb4656da4b6d9469d>

Webrev: https://openjdk.github.io/cr/?repo=jdk8u-dev&pr=18&range=00 <https://openjdk.github.io/cr/?repo=jdk8u-dev&pr=18&range=00>
PR: https://github.com/openjdk/jdk8u-dev/pull/18 <https://github.com/openjdk/jdk8u-dev/pull/18>

Thanks,
tianshuang

From andrew at openjdk.java.net  Wed May  4 15:13:51 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 4 May 2022 15:13:51 GMT
Subject: [jdk8u] RFR: Merge jdk8u-dev:master
Message-ID: <JxoDLHAEYu40RDJGylJ0bVoiKl9r2nzRLf9xXwCaqjc=.39a5cdd3-a6ae-46cd-81fa-a44ca12303e2@github.com>

8u342-b01 build promotion

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

Commit messages:
 - Merge
 - 8285445: cannot open file "NUL:"
 - 8284772: 8u GHA: Use GCC Major Version Dependencies Only
 - Merge
 - 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream
 - 8261107: ArrayIndexOutOfBoundsException in the ICC_Profile.getInstance(InputStream)
 - 8253424: Add support for running pre-submit testing using GitHub Actions
 - 8281814: Debuginfo.diz contains redundant build path after backport JDK-8025936
 - 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale
 - 8274751: Drag And Drop hangs on Windows
 - ... and 11 more: https://git.openjdk.java.net/jdk8u/compare/ee82a7d9...1bc3be25

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

Changes: https://git.openjdk.java.net/jdk8u/pull/8/files
  Stats: 7073 lines in 74 files changed: 5877 ins; 927 del; 269 mod
  Patch: https://git.openjdk.java.net/jdk8u/pull/8.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u pull/8/head:pull/8

PR: https://git.openjdk.java.net/jdk8u/pull/8

From andrew at openjdk.java.net  Wed May  4 15:49:37 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 4 May 2022 15:49:37 GMT
Subject: [jdk8u] RFR: Merge jdk8u-dev:master [v2]
In-Reply-To: <JxoDLHAEYu40RDJGylJ0bVoiKl9r2nzRLf9xXwCaqjc=.39a5cdd3-a6ae-46cd-81fa-a44ca12303e2@github.com>
References: <JxoDLHAEYu40RDJGylJ0bVoiKl9r2nzRLf9xXwCaqjc=.39a5cdd3-a6ae-46cd-81fa-a44ca12303e2@github.com>
Message-ID: <PRCz79y29ZoBw_X7TldlUpex6Q3-jsRFexPK_ojr998=.3b7c80f5-8835-401b-94af-ae84c08b6976@github.com>

> 8u342-b01 build promotion

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u/pull/8/files
  - new: https://git.openjdk.java.net/jdk8u/pull/8/files/1bc3be25..1bc3be25

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk8u&pr=8&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk8u&pr=8&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk8u/pull/8.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u pull/8/head:pull/8

PR: https://git.openjdk.java.net/jdk8u/pull/8

From iris at openjdk.java.net  Wed May  4 15:49:38 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 4 May 2022 15:49:38 GMT
Subject: [jdk8u] Withdrawn: Merge jdk8u-dev:master
In-Reply-To: <JxoDLHAEYu40RDJGylJ0bVoiKl9r2nzRLf9xXwCaqjc=.39a5cdd3-a6ae-46cd-81fa-a44ca12303e2@github.com>
References: <JxoDLHAEYu40RDJGylJ0bVoiKl9r2nzRLf9xXwCaqjc=.39a5cdd3-a6ae-46cd-81fa-a44ca12303e2@github.com>
Message-ID: <QZKD1gGVQe1V0MGue1juAB8Z9xYOTSNrgEJRyGr1HrQ=.b03be579-e700-467d-8109-0194bff1eafc@github.com>

On Wed, 4 May 2022 15:09:18 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> 8u342-b01 build promotion

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk8u/pull/8

From aleksandar.ivanisevic at 2e-systems.com  Wed May  4 15:51:16 2022
From: aleksandar.ivanisevic at 2e-systems.com (Aleksandar Ivanisevic)
Date: Wed, 4 May 2022 17:51:16 +0200
Subject: number of cpus detection still buggy
Message-ID: <FA4837A0-D120-47E0-A10B-D89384607223@2e-systems.com>

Hi,

looks like number of CPUs detection is still buggy in u332, if there is a core online with a logical number bigger than the total number of cores allocated to the (LXD, maybe also some docker implemantations) container in /sys/devices/system/cpu/online, it does not get counted, JRE counts only the ones with a ?possible? number, i.e. if there are 8 cores allocated, only cores 0-7 are counted

# cat Cpus.java
class Cpus {
    public static void main(String[] args) {
        System.out.println("Number of processors available to this JVM: " + Runtime.getRuntime().availableProcessors());
    }
}

# java -version
openjdk version "1.8.0_332"
OpenJDK Runtime Environment (Zulu 8.62.0.19-CA-linux64) (build 1.8.0_332-b09)
OpenJDK 64-Bit Server VM (Zulu 8.62.0.19-CA-linux64) (build 25.332-b09, mixed mode)

# cat /sys/devices/system/cpu/online
3,8-10,13,22,25,28

# java Cpus
Number of processors available to this JVM: 1

so only core number 3 is counted. This is especially funny when no cores are within range, them jre thinks it has 0 CPUs and all sorts of hilarity ensues ;)

if I get rid of /sys/devices/system/cpu/online, or override number of cores with -XX:ActiveProcessorCount=  all is well

# umount /sys/devices/system/cpu
# java Cpus
Number of processors available to this JVM: 8

but this is really hard to diagnose, as the errors are for some reason mostly 

random java.lang.NoClassDefFoundError exceptions
JRE crashing on startup with a segmentation fault in "# V  [libjvm.so+0x95eb25]  ParNewGeneration::collect(bool, bool, unsigned long, bool)+0x95?. 
maven dying with "Error assembling JAR: / by zero?

(just putting this down in hope people might find it googling ;)

java11 does not have that problem. How does one go about getting this fixed so that people do not waste more time with this than its necessary?  I?m just a lowly sysadmin that lost two days of his life on this, not really enlightened how things are going with JVM development.

Thank you.

-- 
Aleksandar Ivanisevic
Head of Operations and Support
2e Systems

Tel: +49 - 6196 - 950 58 14
Fax: +49 - 6196 - 950 58 94
E-mail: Aleksandar.Ivanisevic at 2e-systems.com

Address: 2e Systems GmbH,  Koenigsteiner Str. 107, 65812 Bad Soden am Taunus
Company registration: Amtsgericht Koenigstein (Germany), HRB 7303
Director: Philip Douglas

http://www.2e-systems.com - making your business fly!



From neeraj.jnumca07 at gmail.com  Wed May  4 17:21:47 2022
From: neeraj.jnumca07 at gmail.com (neeraj kumar)
Date: Wed, 4 May 2022 22:51:47 +0530
Subject: OracleJDK update release mapping with openJdk
Message-ID: <CACy-ygRJ5b+8kbGskvjy0oKdYkHvVF+k6wdrpwWqPk1makTqag@mail.gmail.com>

Hello experts,

I am struggling to find out how to map oracle JDK updates with that of
openjdk.

Basically, I want to know which openjdk 8 version/update has the fixes
adressed under the Oracle JDK 8u241.
https://www.oracle.com/java/technologies/javase/8u241-relnotes.html

Any guidance will be helpful.

Thanks,
Neeraj

-- 
~~ Neeraj
LinkedIn <http://in.linkedin.com/pub/neeraj-kumar/13/779/a79/> | Blog
<http://susenj.wordpress.com/> | Quora
<http://www.quora.com/Neeraj-Sinha-19>

From ecki at zusammenkunft.net  Wed May  4 17:49:12 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 4 May 2022 17:49:12 +0000
Subject: OracleJDK update release mapping with openJdk
In-Reply-To: <CACy-ygRJ5b+8kbGskvjy0oKdYkHvVF+k6wdrpwWqPk1makTqag@mail.gmail.com>
References: <CACy-ygRJ5b+8kbGskvjy0oKdYkHvVF+k6wdrpwWqPk1makTqag@mail.gmail.com>
Message-ID: <DBAP193MB1145E8FC1074C26D49A5B5D3FFC39@DBAP193MB1145.EURP193.PROD.OUTLOOK.COM>

Hello,

For Oracle the detailed fix list is usually on a separate bugfix page linked at the end of the release notes: https://www.oracle.com/java/technologies/javase/8u241-bugfixes.html

You also must check if your installation is the GA version or a BPR version, which is oracles commercial patch offering on top of that.

Normally OpenJDK and Oracle are more or less in lockstep. There are some issues which show up in one or the other sooner or later. It?s best if you check the bug number (if it is visible) is marked with a integrated (or backported) version.

For the versions where you have a CPU and PSU version the CPU contain less (only security patches relative to last PSU version) updates as the (higher number) OpenJDK PSU Version. Normally all security fixed are however in both.

So (without checking the details), OpenJDK 8u242 may contain some more fixes than Oracle 8u241 but it should be on the same security level.

There is also a list of absent changes on the page https://wiki.openjdk.java.net/display/jdk8u/Main

It needs to be mentioned that OpenJDK distributions might decide to include less or more changes than the stock OpenJDK source/binaries. For example Azul maintains CPU versions for Zulu11 which OpenJDK does not.

There are also Oracle BPRs. Which basically contain deleted additional fixes, they are however most often contained in the next OpenJDK release.

For example 8u241b32 contains bug 8234468 which is (maybe) contained in OpenJDK8u242

https://www.oracle.com/java/technologies/javase/products-doc-8u241-revision-builds-relnotes.html

And to give you a very practical advice, just update and don?t worry about a 2 years old release.

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> im Auftrag von neeraj kumar <neeraj.jnumca07 at gmail.com>
Gesendet: Wednesday, May 4, 2022 7:21:47 PM
An: jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Betreff: OracleJDK update release mapping with openJdk

Hello experts,

I am struggling to find out how to map oracle JDK updates with that of
openjdk.

Basically, I want to know which openjdk 8 version/update has the fixes
adressed under the Oracle JDK 8u241.
https://www.oracle.com/java/technologies/javase/8u241-relnotes.html

Any guidance will be helpful.

Thanks,
Neeraj

--
~~ Neeraj
LinkedIn <http://in.linkedin.com/pub/neeraj-kumar/13/779/a79/> | Blog
<http://susenj.wordpress.com/> | Quora
<http://www.quora.com/Neeraj-Sinha-19>

From phh at openjdk.java.net  Wed May  4 22:58:26 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Wed, 4 May 2022 22:58:26 GMT
Subject: [jdk8u-dev] RFR: 8248876: LoadObject with bad base address created
 for exec file on linux
In-Reply-To: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
References: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
Message-ID: <rglViKmgdgcecY9_NxEXxcqwvhaexfOPCoyWDi6xORM=.45882540-04ca-48bb-ad22-c1be1789fec7@github.com>

On Mon, 25 Apr 2022 08:08:21 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> I would like to backport
> 8248876: LoadObject with bad base address created for exec file on linux.
> 
> The original patch does not apply cleanly to 8u, and this is a clean backport from 11u.
> 
> Testing:
> build on Linux x86_64
> tier1 on Linux x86_64

Confirmed the backport from 11u is clean.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/47

From phh at openjdk.java.net  Wed May  4 23:02:26 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Wed, 4 May 2022 23:02:26 GMT
Subject: [jdk8u-dev] RFR: 8248876: LoadObject with bad base address created
 for exec file on linux
In-Reply-To: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
References: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
Message-ID: <vP_hnbnI-r0jwBAT0slIta_SvXcs535BWli2gw6_17U=.b3ddd517-db18-4faa-aa53-1bbb60114cde@github.com>

On Mon, 25 Apr 2022 08:08:21 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> I would like to backport
> 8248876: LoadObject with bad base address created for exec file on linux.
> 
> The original patch does not apply cleanly to 8u, and this is a clean backport from 11u.
> 
> Testing:
> build on Linux x86_64
> tier1 on Linux x86_64

Pref-submit build failures appear to be due to incompatible compilers.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/47

From duke at openjdk.java.net  Thu May  5 01:36:26 2022
From: duke at openjdk.java.net (Poison)
Date: Thu, 5 May 2022 01:36:26 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
Message-ID: <kdfP6OJtnrajctdzNe1nwwyB1LnNGjaRsOfnujo6Kgk=.e3686649-456c-4402-8375-b97131393bd6@github.com>

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

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

waiting for reviewer's review...

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

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

From aph-open at littlepinkcloud.com  Thu May  5 11:33:35 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Thu, 5 May 2022 12:33:35 +0100
Subject: Port of JEP 386: Alpine Linux Port to jdk8u
In-Reply-To: <DM6PR21MB161059D978862BE722863B9AA1FD9@DM6PR21MB1610.namprd21.prod.outlook.com>
References: <DM6PR21MB161059D978862BE722863B9AA1FD9@DM6PR21MB1610.namprd21.prod.outlook.com>
Message-ID: <f3c283cb-01a7-ae89-d6e7-709ece6999c7@littlepinkcloud.com>

On 4/28/22 18:16, Stephanie Crater wrote:
> Would the community be open to a port of JEP 386: Alpine Linux Port [1]/JDK-8247589 [2] to OpenJDK jdk8u? A backport of JDK-8247589 to 11u has recently been integrated by BellSoft, and many OpenJDK vendors (BellSoft Liberica, Azul Zulu, Amazon Corretto) provide a jdk8 for Alpine Linux. We believe there is sufficient user demand for Alpine/musl support on jdk8u, but would be interested in the opinions of other vendors on this as well.

In principle, yes. I don't much like the actual patch, which sprinkles
changes like

#ifndef MUSL_LIBC
#include <sys/poll.h>
#else
#include <poll.h>
#endif

and (Yuck! Could they really not have factored this in a better way?)

+#ifndef MUSL_LIBC
    st->print("pc =" INTPTR_FORMAT "  ", uc->uc_mcontext.regs->nip);
    st->print("lr =" INTPTR_FORMAT "  ", uc->uc_mcontext.regs->link);
    st->print("ctr=" INTPTR_FORMAT "  ", uc->uc_mcontext.regs->ctr);
@@ -576,6 +604,16 @@ void os::print_context(outputStream *st, void *context) {
      st->print("r%-2d=" INTPTR_FORMAT "  ", i, uc->uc_mcontext.regs->gpr[i]);
      if (i % 3 == 2) st->cr();
    }
+#else // Musl
+  st->print("pc =" INTPTR_FORMAT "  ", uc->uc_mcontext.gp_regs[PT_NIP]);
+  st->print("lr =" INTPTR_FORMAT "  ", uc->uc_mcontext.gp_regs[PT_LNK]);
+  st->print("ctr=" INTPTR_FORMAT "  ", uc->uc_mcontext.gp_regs[PT_CTR]);
+  st->cr();
+  for (int i = 0; i < 32; i++) {
+    st->print("r%-2d=" INTPTR_FORMAT "  ", i, uc->uc_mcontext.gp_regs[i]);
+    if (i % 3 == 2) st->cr();
+  }

in many places, but I have to admit that none of it looks very risky.
My concern is more to do with maintainability, with #ifndef MUSL_LIBC
occurring 25 times in the patch. But we're supposed to change patches
as little as possible when 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 aleksei.voitylov at bell-sw.com  Thu May  5 14:32:02 2022
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Thu, 5 May 2022 17:32:02 +0300
Subject: Port of JEP 386: Alpine Linux Port to jdk8u
In-Reply-To: <DM6PR21MB161059D978862BE722863B9AA1FD9@DM6PR21MB1610.namprd21.prod.outlook.com>
References: <DM6PR21MB161059D978862BE722863B9AA1FD9@DM6PR21MB1610.namprd21.prod.outlook.com>
Message-ID: <7876ea4d-e923-91d5-039f-0433863870b4@bell-sw.com>

Hi Stephanie,

when briefly looking through the changed filenames I stumbled upon
cpu/ppc/vm, os_cpu/linux_ppc/vm and couldn't recollect having to touch
these directories in JEP 386. So, I wanted to ask a question:

Is this a backport of the set of changes that were committed upstream to
OpenJDK 16 in JEP 386 (or a backport from 11u backports I recently did)?
Or is this some original work Microsoft has done for 8u shared code and
PPC in particular?

Thanks,

-Aleksei

On 28/04/2022 20:16, Stephanie Crater wrote:
> Hi,
>
> Would the community be open to a port of JEP 386: Alpine Linux Port [1]/JDK-8247589 [2] to OpenJDK jdk8u? A backport of JDK-8247589 to 11u has recently been integrated by BellSoft, and many OpenJDK vendors (BellSoft Liberica, Azul Zulu, Amazon Corretto) provide a jdk8 for Alpine Linux. We believe there is sufficient user demand for Alpine/musl support on jdk8u, but would be interested in the opinions of other vendors on this as well.
>
> Microsoft is part of the Eclipse Adoptium Working Group and has recently trialed a patch which was applied to the 8u322 tag on the jdk8u source tree (for Eclipse Temurin binary production)[3]. That 8u322 based binary passes builds on all platforms (i.e. No regressions on other platforms) and the AQAVit test suite. The Eclipse Temurin Compliance group also reported that the TCK passed.
>
> We would be willing to maintain Alpine Linux in jdk8u but would prefer that there is broad support. Please let me know what you think or if there are any concerns you may have regarding the proposal of this backport.
>
> Thanks,
> Stephanie
>
> [1] https://openjdk.java.net/jeps/386
> [2] https://bugs.openjdk.java.net/browse/JDK-8247589
> [3] https://github.com/adoptium/jdk8u/pull/9
>


From duke at openjdk.java.net  Thu May  5 20:26:42 2022
From: duke at openjdk.java.net (Joshua Cao)
Date: Thu, 5 May 2022 20:26:42 GMT
Subject: [jdk8u-dev] RFR: 8168926: C2: Bytecode escape analyzer crashes due to
 stack overflow
Message-ID: <zr61DLQuPvxa6-asQ_efIbsoZ_VZyFocEb3UcIUHqT0=.364c0a8d-1b23-46a0-9798-023d803c0779@github.com>

This is a clean backport of [8168926](https://bugs.openjdk.java.net/browse/JDK-8168926) from openjdk/jdk repository. Passing `make test`.

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

Commit messages:
 - Backport 421bf2f22d4ebbdd92ba0476a7dc33b20528827a

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/53/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=53&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8168926
  Stats: 35 lines in 2 files changed: 29 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/53.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/53/head:pull/53

PR: https://git.openjdk.java.net/jdk8u-dev/pull/53

From phh at openjdk.java.net  Thu May  5 21:29:59 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 5 May 2022 21:29:59 GMT
Subject: [jdk8u-dev] RFR: 8168926: C2: Bytecode escape analyzer crashes due
 to stack overflow
In-Reply-To: <zr61DLQuPvxa6-asQ_efIbsoZ_VZyFocEb3UcIUHqT0=.364c0a8d-1b23-46a0-9798-023d803c0779@github.com>
References: <zr61DLQuPvxa6-asQ_efIbsoZ_VZyFocEb3UcIUHqT0=.364c0a8d-1b23-46a0-9798-023d803c0779@github.com>
Message-ID: <trrpYrtcZQuvvrla50dbq7XszAzbYy6t1ZOCqfwBSJE=.fb40a06b-d105-45db-a894-816620b2bf59@github.com>

On Thu, 5 May 2022 20:20:23 GMT, Joshua Cao <duke at openjdk.java.net> wrote:

> This is a clean backport of [8168926](https://bugs.openjdk.java.net/browse/JDK-8168926) from openjdk/jdk repository. Passing `make test`.

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/53

From magnus.ihse.bursie at oracle.com  Fri May  6 13:10:04 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 6 May 2022 15:10:04 +0200
Subject: [aarch64-port-dev ] 8u332 Release
In-Reply-To: <ac63933-2d67-6a8c-47da-a214e47886be@tarent.de>
References: <Yl/92k7+fnwtzmuo@hex.discworld.ac.uk>
 <b841e884-142f-aeee-8842-18805412d3c@tarent.de>
 <YmXThyOqbDDv+Ezd@hex.discworld.ac.uk>
 <ac63933-2d67-6a8c-47da-a214e47886be@tarent.de>
Message-ID: <f9d37406-4420-dbd9-66a1-589ea60761ea@oracle.com>

On 2022-04-25 00:55, Thorsten Glaser wrote:
> Hi Andrew,
>
>> It's going to take a while to get the changes into the official
>> repository - https://github.com/openjdk/shenandoah-jdk8u - because
>> we're still fighting with the SKARA commit system there.
> oh, ouch. What does SKARA stand for, anyway? (Or is it not an acronym?)
It's arbitrarily named after a Swedish town.[1] (We usually do not 
capitalize it, since it is not an acronym.) The name was used as a 
project name but lingered on as the name of the system of services 
developed as part of that project.

/Magnus

[1] https://en.wikipedia.org/wiki/Skara
>
>> Note that we've dropped the 'aarch64-' prefix from this release on, as
>> the AArch64 port has been in upstream 8u for some time; the only
>> difference in this fork is the availability of the Shenandoah garbage
>> collector.
> Indeed; someone, maybe you, wrote something like this a few months ago,
> and I recalled that and, over this weekend, did test whether we can use
> just the normal code for arm64, leaving us with only the aarch32 stuff
> for armhf (armel uses Zero) as extra repository. I was able to confirm
> it works (for several, albeit smallish, Maven projects) on a porterbox
> and am switching the Debian packaging of OpenJDK 8 to it.
>
> Thanks,
> //mirabilos


From darcy at openjdk.java.net  Fri May  6 22:37:30 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 6 May 2022 22:37:30 GMT
Subject: [jdk8u-ri] RFR: JDK-8285497: Add system property for Java SE
 specification maintenance version
Message-ID: <THxDT63s1ZaEWmsoyBIdKUTRNS13iTkzbdrRlhZgf6s=.a2afda8b-519e-4e94-a7fa-61de280e229f@github.com>

Backport of change from JDK 19.

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

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

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/8

From mchung at openjdk.java.net  Fri May  6 23:54:40 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 6 May 2022 23:54:40 GMT
Subject: [jdk8u-ri] RFR: JDK-8285497: Add system property for Java SE
 specification maintenance version
In-Reply-To: <THxDT63s1ZaEWmsoyBIdKUTRNS13iTkzbdrRlhZgf6s=.a2afda8b-519e-4e94-a7fa-61de280e229f@github.com>
References: <THxDT63s1ZaEWmsoyBIdKUTRNS13iTkzbdrRlhZgf6s=.a2afda8b-519e-4e94-a7fa-61de280e229f@github.com>
Message-ID: <bshfyeeQbfMBLpc3FDdeJ8ptzBSR5LcH5LtFfSC9Emw=.d8cfc344-67dc-409a-bf73-b9430233c122@github.com>

On Fri, 6 May 2022 21:52:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Backport of change from JDK 19.

Looks good to me.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/8

From iris at openjdk.java.net  Sat May  7 00:58:48 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Sat, 7 May 2022 00:58:48 GMT
Subject: [jdk8u-ri] RFR: JDK-8285497: Add system property for Java SE
 specification maintenance version
In-Reply-To: <THxDT63s1ZaEWmsoyBIdKUTRNS13iTkzbdrRlhZgf6s=.a2afda8b-519e-4e94-a7fa-61de280e229f@github.com>
References: <THxDT63s1ZaEWmsoyBIdKUTRNS13iTkzbdrRlhZgf6s=.a2afda8b-519e-4e94-a7fa-61de280e229f@github.com>
Message-ID: <yuthYfuN1zbF-14mi102NsTB1vvGi3f3M7wfkci-J8w=.cd74c71b-6523-4a3d-88cc-7ad001766015@github.com>

On Fri, 6 May 2022 21:52:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Backport of change from JDK 19.

Marked as reviewed by iris (Author).

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/8

From andrew at openjdk.java.net  Mon May  9 03:03:57 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 9 May 2022 03:03:57 GMT
Subject: [jdk8u-dev] RFR: 8235211:
 serviceability/attach/RemovingUnixDomainSocketTest.java fails with
 AttachNotSupportedException: Unable to open socket file [v3]
In-Reply-To: <28wtpv5RkiKCJQflaaNnUJlrnciqqvE6hLqYb2R-i8s=.c2a620b8-4407-4a2b-8934-2fa211b0b775@github.com>
References: <hK4acmjE3fCMdejaICnkW6V5GS-36zcUx_cD8EzjfKI=.996f8254-7e4e-47c1-95ce-4d798e06f51f@github.com>
 <28wtpv5RkiKCJQflaaNnUJlrnciqqvE6hLqYb2R-i8s=.c2a620b8-4407-4a2b-8934-2fa211b0b775@github.com>
Message-ID: <dqJqd1ysl2JSwlQ8io8QBGKZ1h21uO2c2enmiROpvV0=.0d54b528-dccb-47a6-a314-2ea88eabbe30@github.com>

On Wed, 6 Apr 2022 00:04:20 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Hi, 
>> 
>> Could you review this backport of 8235211? This is a follow up of JDK-8225690.
>> 
>> 
>> This patch can't be applied to jdk8u cleanly. We replace os::naked_yield with os::yield(), which is available in jdk8u and have same implementations on Linux/BSD/AIX.  Except for that, all other changes are just path adjustment. 
>> 
>> There's a deadlock in the original backport. Both Signal dispatcher(refer to S for short) and AttachListener(A) are Java Threads.  Therefore, they are subject to safepoint synchronization.
>> 
>> A sets `_state` to AL_INITIALIZED and then get blocked at a safepoint(maybe AttachListener::dequeue).
>> If the socket file is deleted and JVM receive SIGQUIT the, S realizes that the socket file has gone in `check_socket_file` and start to reinitialize it. It falls into this loop and prevent itself from reaching the safepoint.
>> 
>>      while (AttachListener::transit_state(AL_INITIALIZING,
>>                                            AL_NOT_INITIALIZED) != AL_NOT_INITIALIZED) {
>>         os::naked_yield();
>>       }
>> 
>> 
>> If A waked up and realized that the socket has gone,  it would set `_state` to AL_NOT_INITIALIZED. Current code is adeadlock.  A can?t wake up because S hasn?t reached the safepoint yet. S can?t reach the safepoint because A hasn?t set _state to AL_NOT_INITIALIZED.  This patch avoids the deadlock by trapping into blocked state before the loop.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo when we manually edited the two test files.
>   
>   Currently, RemovingUnixDomainSocketTest.java isn't running because @test
>   is taken away when we backport JDK-8225690. we try to keep the patch
>   intact in case we enable it in the future.

Looks good to me. Clean backport bar the naked_yield/yield change.

Added `jdk8u-fix-yes`.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/32

From duke at openjdk.java.net  Mon May  9 06:47:58 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Mon, 9 May 2022 06:47:58 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <_GJVqpp416f4KQK5veJZh2YRsaZRgnLfT4sCzjLlvKs=.aff167f8-0513-42ef-832d-396023fa72f2@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
 <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
 <_GJVqpp416f4KQK5veJZh2YRsaZRgnLfT4sCzjLlvKs=.aff167f8-0513-42ef-832d-396023fa72f2@github.com>
Message-ID: <WYLx80cfWCI78fijou70gC2RaBa3twV1-reMP1D5iK0=.7fc77fb0-527e-48f8-88f1-6704ac53f8ad@github.com>

On Tue, 26 Apr 2022 06:23:39 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

>> ktakakuri has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update jdk/make/Images.gmk
>>   
>>   Co-authored-by: Joakim Nordstr?m <joakim.nordstrom at oracle.com>
>
> This needs to be approved according to https://wiki.openjdk.java.net/display/jdk8u/Main#Main-FixApprovals
> I'm in the process of adding the needed labels to the JBS issue, and then a maintainer will take care of the approval.

@jaokim 
Thank you for adding the label.

@erikj79 
Would you please be a sponsor?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From duke at openjdk.java.net  Mon May  9 08:22:07 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Mon, 9 May 2022 08:22:07 GMT
Subject: [jdk8u-dev] RFR: 8248876: LoadObject with bad base address created
 for exec file on linux
In-Reply-To: <vP_hnbnI-r0jwBAT0slIta_SvXcs535BWli2gw6_17U=.b3ddd517-db18-4faa-aa53-1bbb60114cde@github.com>
References: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
 <vP_hnbnI-r0jwBAT0slIta_SvXcs535BWli2gw6_17U=.b3ddd517-db18-4faa-aa53-1bbb60114cde@github.com>
Message-ID: <xEjj7_6PTVWDfkH14jR2CnC0eSsuICEGzZXxzPtkDAs=.30cd4b17-d387-49dc-808c-ad562a213522@github.com>

On Wed, 4 May 2022 22:59:15 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> I would like to backport
>> 8248876: LoadObject with bad base address created for exec file on linux.
>> 
>> The original patch does not apply cleanly to 8u, and this is a clean backport from 11u.
>> 
>> Testing:
>> build on Linux x86_64
>> tier1 on Linux x86_64
>
> Pref-submit build failures appear to be due to incompatible compilers.

@phohensee 
Thank you for your review.
I am not sure if I should continue to integrate.
Is there any other work that needs to be done?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/47

From phh at openjdk.java.net  Mon May  9 10:52:49 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Mon, 9 May 2022 10:52:49 GMT
Subject: [jdk8u-dev] RFR: 8248876: LoadObject with bad base address created
 for exec file on linux
In-Reply-To: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
References: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
Message-ID: <W-TWFxRBno4Mxix2zgJ0ycChSB9bHqC7y0c6XkxtuiI=.af2fd038-b35a-4118-903e-c4541025ca34@github.com>

On Mon, 25 Apr 2022 08:08:21 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> I would like to backport
> 8248876: LoadObject with bad base address created for exec file on linux.
> 
> The original patch does not apply cleanly to 8u, and this is a clean backport from 11u.
> 
> Testing:
> build on Linux x86_64
> tier1 on Linux x86_64

Yes. You need to tag the JBS issue with 'jdk8u-fix-request' and wait for a maintainer to approve it by adding the 'jdk8u-fix-yes' tag. Once that's done, you can integrate it. I'll sponsor if you like.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/47

From xliu at openjdk.java.net  Mon May  9 16:42:00 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 9 May 2022 16:42:00 GMT
Subject: [jdk8u-dev] Integrated: 8235211:
 serviceability/attach/RemovingUnixDomainSocketTest.java fails with
 AttachNotSupportedException: Unable to open socket file
In-Reply-To: <hK4acmjE3fCMdejaICnkW6V5GS-36zcUx_cD8EzjfKI=.996f8254-7e4e-47c1-95ce-4d798e06f51f@github.com>
References: <hK4acmjE3fCMdejaICnkW6V5GS-36zcUx_cD8EzjfKI=.996f8254-7e4e-47c1-95ce-4d798e06f51f@github.com>
Message-ID: <bqkGVUQdvJFGHWLRJJukt2Z9tPReTIPXLhHZGx3t0Y4=.c40e7fed-7b7e-468b-b697-1437dd104dbd@github.com>

On Tue, 5 Apr 2022 00:55:22 GMT, Xin Liu <xliu at openjdk.org> wrote:

> Hi, 
> 
> Could you review this backport of 8235211? This is a follow up of JDK-8225690.
> 
> 
> This patch can't be applied to jdk8u cleanly. We replace os::naked_yield with os::yield(), which is available in jdk8u and have same implementations on Linux/BSD/AIX.  Except for that, all other changes are just path adjustment. 
> 
> There's a deadlock in the original backport. Both Signal dispatcher(refer to S for short) and AttachListener(A) are Java Threads.  Therefore, they are subject to safepoint synchronization.
> 
> A sets `_state` to AL_INITIALIZED and then get blocked at a safepoint(maybe AttachListener::dequeue).
> If the socket file is deleted and JVM receive SIGQUIT the, S realizes that the socket file has gone in `check_socket_file` and start to reinitialize it. It falls into this loop and prevent itself from reaching the safepoint.
> 
>      while (AttachListener::transit_state(AL_INITIALIZING,
>                                            AL_NOT_INITIALIZED) != AL_NOT_INITIALIZED) {
>         os::naked_yield();
>       }
> 
> 
> If A waked up and realized that the socket has gone,  it would set `_state` to AL_NOT_INITIALIZED. Current code is adeadlock.  A can?t wake up because S hasn?t reached the safepoint yet. S can?t reach the safepoint because A hasn?t set _state to AL_NOT_INITIALIZED.  This patch avoids the deadlock by trapping into blocked state before the loop.

This pull request has now been integrated.

Changeset: 1067c545
Author:    Xin Liu <xliu at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/1067c545658ff0643ad625073f4fddc2f7a0daf0
Stats:     70 lines in 5 files changed: 37 ins; 2 del; 31 mod

8235211: serviceability/attach/RemovingUnixDomainSocketTest.java fails with AttachNotSupportedException: Unable to open socket file
8244973: serviceability/attach/RemovingUnixDomainSocketTest.java fails "stderr was not empty"

Reviewed-by: phh, andrew
Backport-of: 073e095e6053550b17b1daf33df2be4f4c4b40ad

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/32

From zgu at openjdk.java.net  Mon May  9 19:07:24 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 9 May 2022 19:07:24 GMT
Subject: [jdk8u-dev] RFR: 8073464: GC workers do not have thread names
Message-ID: <trkPo6JqGGK5Y0EihU8AsEGB3HBHSSXV9kbX-k_EO4I=.08584ca0-fdaa-47dc-8776-f816ce409985@github.com>

Backport for parity with Oracle 8u351.

The original patch does not apply cleanly, applied manully.

Test:

- [x] runtime on Linux x86_64

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

Commit messages:
 - Backport a827cdfa1047ee0af30bb454aad2067420103bae

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/56/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=56&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8073464
  Stats: 16 lines in 7 files changed: 8 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/56.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/56/head:pull/56

PR: https://git.openjdk.java.net/jdk8u-dev/pull/56

From dongbohe at openjdk.java.net  Tue May 10 01:12:56 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Tue, 10 May 2022 01:12:56 GMT
Subject: [jdk8u-dev] RFR: 8170530: bash configure output contains a typo in
 a suggested library name
In-Reply-To: <UXqCEc71ix0Ck9WguJnG0OOEsycAed8FRxF9LFmIo2c=.4972f002-c98d-4cf6-bc36-dc4f48cb6911@github.com>
References: <UXqCEc71ix0Ck9WguJnG0OOEsycAed8FRxF9LFmIo2c=.4972f002-c98d-4cf6-bc36-dc4f48cb6911@github.com>
Message-ID: <SC-ucDElOtUZDSRuMhOPULTwfdoZ2T2BxbN56ZIIxAg=.9854616c-da23-4306-9aea-c0f474c129af@github.com>

On Fri, 1 Apr 2022 01:55:54 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this patch to fix a typo in a suggested library name.
> I updated `DATE_WHEN_GENERATED` with `date +%s`, and other parts are clean.
> 
> Testing: worked correctly after patch.

Got the push approval.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/28

From dongbohe at openjdk.java.net  Tue May 10 01:17:57 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Tue, 10 May 2022 01:17:57 GMT
Subject: [jdk8u-dev] Integrated: 8170530: bash configure output contains a typo
 in a suggested library name
In-Reply-To: <UXqCEc71ix0Ck9WguJnG0OOEsycAed8FRxF9LFmIo2c=.4972f002-c98d-4cf6-bc36-dc4f48cb6911@github.com>
References: <UXqCEc71ix0Ck9WguJnG0OOEsycAed8FRxF9LFmIo2c=.4972f002-c98d-4cf6-bc36-dc4f48cb6911@github.com>
Message-ID: <Sv_AMHeYrBN4wCTatepFhp0AyNZ6nH-1fGL9s6qNBt0=.f443f201-a4a4-4e34-acb7-a66fdd510fce@github.com>

On Fri, 1 Apr 2022 01:55:54 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this patch to fix a typo in a suggested library name.
> I updated `DATE_WHEN_GENERATED` with `date +%s`, and other parts are clean.
> 
> Testing: worked correctly after patch.

This pull request has now been integrated.

Changeset: 1b3e8ea8
Author:    Dongbo He <dongbohe at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/1b3e8ea8ec14b462e86603d3ec6f35173d066541
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8170530: bash configure output contains a typo in a suggested library name

Reviewed-by: sgehwolf
Backport-of: 5c5ffe13e3dced0962ce2b137c1c3b30f2f3a924

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/28

From aleksandar.ivanisevic at 2e-systems.com  Tue May 10 08:53:52 2022
From: aleksandar.ivanisevic at 2e-systems.com (Aleksandar Ivanisevic)
Date: Tue, 10 May 2022 10:53:52 +0200
Subject: number of cpus detection still buggy
In-Reply-To: <FA4837A0-D120-47E0-A10B-D89384607223@2e-systems.com>
References: <FA4837A0-D120-47E0-A10B-D89384607223@2e-systems.com>
Message-ID: <EFBBCAE0-4069-4137-AFA5-07BC59EBF521@2e-systems.com>

As pointed out to me in this thread

https://discuss.linuxcontainers.org/t/online-cpu-numbers-in-sys-devices-system-cpu-online-and-sched-getaffinity-masks/13991

this is perfectly possible and reproducible also in physical machines and full VMs, not only in containers. It is enough to offline a (couple of) CPUs and the bug will be triggered.

Is there any interest by anyone in this being fixed?

> On 4. May 2022, at 17:51, Aleksandar Ivanisevic <aleksandar.ivanisevic at 2e-systems.com> wrote:
> 
> Hi,
> 
> looks like number of CPUs detection is still buggy in u332, if there is a core online with a logical number bigger than the total number of cores allocated to the (LXD, maybe also some docker implemantations) container in /sys/devices/system/cpu/online, it does not get counted, JRE counts only the ones with a ?possible? number, i.e. if there are 8 cores allocated, only cores 0-7 are counted
> 
> # cat Cpus.java
> class Cpus {
>    public static void main(String[] args) {
>        System.out.println("Number of processors available to this JVM: " + Runtime.getRuntime().availableProcessors());
>    }
> }
> 
> # java -version
> openjdk version "1.8.0_332"
> OpenJDK Runtime Environment (Zulu 8.62.0.19-CA-linux64) (build 1.8.0_332-b09)
> OpenJDK 64-Bit Server VM (Zulu 8.62.0.19-CA-linux64) (build 25.332-b09, mixed mode)
> 
> # cat /sys/devices/system/cpu/online
> 3,8-10,13,22,25,28
> 
> # java Cpus
> Number of processors available to this JVM: 1
> 
> so only core number 3 is counted. This is especially funny when no cores are within range, them jre thinks it has 0 CPUs and all sorts of hilarity ensues ;)
> 
> if I get rid of /sys/devices/system/cpu/online, or override number of cores with -XX:ActiveProcessorCount=  all is well
> 
> # umount /sys/devices/system/cpu
> # java Cpus
> Number of processors available to this JVM: 8
> 
> but this is really hard to diagnose, as the errors are for some reason mostly 
> 
> random java.lang.NoClassDefFoundError exceptions
> JRE crashing on startup with a segmentation fault in "# V  [libjvm.so+0x95eb25]  ParNewGeneration::collect(bool, bool, unsigned long, bool)+0x95?. 
> maven dying with "Error assembling JAR: / by zero?
> 
> (just putting this down in hope people might find it googling ;)
> 
> java11 does not have that problem. How does one go about getting this fixed so that people do not waste more time with this than its necessary?  I?m just a lowly sysadmin that lost two days of his life on this, not really enlightened how things are going with JVM development.
> 
> Thank you.
> 
> -- 
> Aleksandar Ivanisevic
> Head of Operations and Support
> 2e Systems
> 
> Tel: +49 - 6196 - 950 58 14
> Fax: +49 - 6196 - 950 58 94
> E-mail: Aleksandar.Ivanisevic at 2e-systems.com
> 
> Address: 2e Systems GmbH,  Koenigsteiner Str. 107, 65812 Bad Soden am Taunus
> Company registration: Amtsgericht Koenigstein (Germany), HRB 7303
> Director: Philip Douglas
> 
> http://www.2e-systems.com - making your business fly!
> 
> 

-- 
Aleksandar Ivanisevic
Head of Operations and Support
2e Systems

Tel: +49 - 6196 - 950 58 14
Fax: +49 - 6196 - 950 58 94
E-mail: Aleksandar.Ivanisevic at 2e-systems.com

Address: 2e Systems GmbH,  Koenigsteiner Str. 107, 65812 Bad Soden am Taunus
Company registration: Amtsgericht Koenigstein (Germany), HRB 7303
Director: Philip Douglas

http://www.2e-systems.com - making your business fly!



From duke at openjdk.java.net  Wed May 11 06:41:59 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Wed, 11 May 2022 06:41:59 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v3]
In-Reply-To: <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
Message-ID: <labnEWK66U7ujg_BuydjCBzOAf652p-u3rUnqiI35V0=.c6621e7e-4128-4f36-99f8-a942118aaf40@github.com>

On Fri, 8 Apr 2022 17:46:57 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. **WARNING**: the patch DOES NOT enable the building with MSVS2019 toolkit, that requires 5-6 more backports. The patch ONLY adds recognition of MSVS2019 to the build system.
>> 
>> The 11u patch applied with the following changes:
>> 
>> - changes to absent documentation files skipped
>> - resolved baseline conflicts toolchain_windows.m4
>> - valid MSVS versions were ascending sorted
>> 
>> Verification: `bash configure` under VS2019 prompt.
>> 
>> Regression:
>> 
>> - VS2017 full build (both 64/32-bit): ok
>> - VS2015 full build: ok (requires --with-extra-cflags='/EHsc /wd4091' --with-extra-cxxflags='/EHsc /wd4091')
>> - VS2013 full build: ok
>> - VS2012 full build: ok
>> - VS2010 full build: ok
>> 
>> @RealCLanger @mdoerr if you take a look at this I will be very grateful
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rearrange valid VS versions

Ping. Can we proceed somehow? There are several more backports required to enable MSVC 2019 support, but they all depend on this one. Thank you

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From duke at openjdk.java.net  Wed May 11 06:44:07 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Wed, 11 May 2022 06:44:07 GMT
Subject: [jdk8u-dev] RFR: 8130895: Test
 javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
Message-ID: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>

I would like to backport
JDK-8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
The original patch applies cleanly after paths changes.

Testing:
build on Solaris11.4 sparcv9
tire1, jdk_awt and javax/swing/system/6799345/TestShutdown.java on Solaris11.4 sparcv9

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

Commit messages:
 - Backport 4140fd05a447c888856c54aee22c475173030833

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/57/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=57&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8130895
  Stats: 49 lines in 2 files changed: 25 ins; 17 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/57.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/57/head:pull/57

PR: https://git.openjdk.java.net/jdk8u-dev/pull/57

From sgehwolf at openjdk.java.net  Wed May 11 08:30:56 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 11 May 2022 08:30:56 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v3]
In-Reply-To: <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
Message-ID: <R1urc0mGoBNKdKwA6-VHVwJFR1qAnMiOe1SqFiJTnLc=.3ae15984-0b51-466e-a506-be58dc6ec989@github.com>

On Fri, 8 Apr 2022 17:46:57 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. **WARNING**: the patch DOES NOT enable the building with MSVS2019 toolkit, that requires 5-6 more backports. The patch ONLY adds recognition of MSVS2019 to the build system.
>> 
>> The 11u patch applied with the following changes:
>> 
>> - changes to absent documentation files skipped
>> - resolved baseline conflicts toolchain_windows.m4
>> - valid MSVS versions were ascending sorted
>> 
>> Verification: `bash configure` under VS2019 prompt.
>> 
>> Regression:
>> 
>> - VS2017 full build (both 64/32-bit): ok
>> - VS2015 full build: ok (requires --with-extra-cflags='/EHsc /wd4091' --with-extra-cxxflags='/EHsc /wd4091')
>> - VS2013 full build: ok
>> - VS2012 full build: ok
>> - VS2010 full build: ok
>> 
>> @RealCLanger @mdoerr if you take a look at this I will be very grateful
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rearrange valid VS versions

OK, though, I have no way to test this myself.

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From duke at openjdk.java.net  Wed May 11 14:06:48 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Wed, 11 May 2022 14:06:48 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v3]
In-Reply-To: <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
Message-ID: <TUHEl-DYDw7dDzcL-jyeDwApEH5NgwPcsu-NOg8VNEU=.2a97ca43-de5a-46e4-83b2-10b2f4138ac2@github.com>

On Fri, 8 Apr 2022 17:46:57 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. **WARNING**: the patch DOES NOT enable the building with MSVS2019 toolkit, that requires 5-6 more backports. The patch ONLY adds recognition of MSVS2019 to the build system.
>> 
>> The 11u patch applied with the following changes:
>> 
>> - changes to absent documentation files skipped
>> - resolved baseline conflicts toolchain_windows.m4
>> - valid MSVS versions were ascending sorted
>> 
>> Verification: `bash configure` under VS2019 prompt.
>> 
>> Regression:
>> 
>> - VS2017 full build (both 64/32-bit): ok
>> - VS2015 full build: ok (requires --with-extra-cflags='/EHsc /wd4091' --with-extra-cxxflags='/EHsc /wd4091')
>> - VS2013 full build: ok
>> - VS2012 full build: ok
>> - VS2010 full build: ok
>> 
>> @RealCLanger @mdoerr if you take a look at this I will be very grateful
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rearrange valid VS versions

[JDK-8221988](https://bugs.openjdk.java.net/browse/JDK-8221988) labelled with jdk8u-fix-request

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From aph at openjdk.java.net  Wed May 11 16:30:57 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 11 May 2022 16:30:57 GMT
Subject: [jdk8u-ri] RFR: JDK-8285497: Add system property for Java SE
 specification maintenance version
In-Reply-To: <THxDT63s1ZaEWmsoyBIdKUTRNS13iTkzbdrRlhZgf6s=.a2afda8b-519e-4e94-a7fa-61de280e229f@github.com>
References: <THxDT63s1ZaEWmsoyBIdKUTRNS13iTkzbdrRlhZgf6s=.a2afda8b-519e-4e94-a7fa-61de280e229f@github.com>
Message-ID: <ZWl2PU0RnV70XWAz4gU_LLf4hErWhXWOEaE6w7GYTjE=.e50fc82d-cc19-4f90-911a-800ba3d482ec@github.com>

On Fri, 6 May 2022 21:52:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Backport of change from JDK 19.

Marked as reviewed by aph (Lead).

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/8

From andrew at openjdk.java.net  Wed May 11 17:03:08 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 11 May 2022 17:03:08 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v2]
In-Reply-To: <D51N-MaVhcUrjtHtLq7S334753-iZYFLuYPo-ljIQDU=.eacc961f-8adc-48d0-ade7-cf6e435e0aa7@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <IFQObOADDSUEfHfnRSoQ_hdtMptt6_tEykLpkZBo_84=.f9b11dad-9fbf-4900-83d3-5f546ec1ab89@github.com>
 <D51N-MaVhcUrjtHtLq7S334753-iZYFLuYPo-ljIQDU=.eacc961f-8adc-48d0-ade7-cf6e435e0aa7@github.com>
Message-ID: <8zSb4WruJpeJWGUXD3KsfPGjBdgYMElXosQ8Y806mps=.a0d043e4-c3e2-41df-8d9b-95fd9802246e@github.com>

On Fri, 8 Apr 2022 17:01:46 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> With which versions of Visual Studio has this been tested?

GHA is testing VS2010 & VS2017, for what it's worth. Currently wondering what broke MacOS (not specific to this fix)

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From andrew at openjdk.java.net  Wed May 11 17:03:09 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 11 May 2022 17:03:09 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v3]
In-Reply-To: <lD9Y-WNIHXlZoWZPGFroDHnoRQ_UvNN4saLOt24XYik=.d438c454-cb60-4244-ab4f-d51ace7eb6ec@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
 <lD9Y-WNIHXlZoWZPGFroDHnoRQ_UvNN4saLOt24XYik=.d438c454-cb60-4244-ab4f-d51ace7eb6ec@github.com>
Message-ID: <9d4XS26FevFPVD6W_zCHe2j37G2gZnmcEltUDnmVm48=.919c0871-ca6b-4425-ac58-d15ea1462826@github.com>

On Sat, 30 Apr 2022 01:08:30 GMT, Martijn Verburg <duke at openjdk.java.net> wrote:

> Hey all - missed this whilst travelling. Happy to help test this internally at MSFT

Extra testing is always welcome :)

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From andrew at openjdk.java.net  Wed May 11 17:36:03 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 11 May 2022 17:36:03 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v3]
In-Reply-To: <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
Message-ID: <6r-ec-t6pDP62JzQAYaGPWHxJfmRDdMKXWLMZSP8OaM=.fc396dc1-a726-437d-91d0-500d524e283a@github.com>

On Fri, 8 Apr 2022 17:46:57 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. **WARNING**: the patch DOES NOT enable the building with MSVS2019 toolkit, that requires 5-6 more backports. The patch ONLY adds recognition of MSVS2019 to the build system.
>> 
>> The 11u patch applied with the following changes:
>> 
>> - changes to absent documentation files skipped
>> - resolved baseline conflicts toolchain_windows.m4
>> - valid MSVS versions were ascending sorted
>> 
>> Verification: `bash configure` under VS2019 prompt.
>> 
>> Regression:
>> 
>> - VS2017 full build (both 64/32-bit): ok
>> - VS2015 full build: ok (requires --with-extra-cflags='/EHsc /wd4091' --with-extra-cxxflags='/EHsc /wd4091')
>> - VS2013 full build: ok
>> - VS2012 full build: ok
>> - VS2010 full build: ok
>> 
>> @RealCLanger @mdoerr if you take a look at this I will be very grateful
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rearrange valid VS versions

Backport looks good to me and GHA suggests it doesn't break existing builds on VS2010 & VS2017.

There is documentation in 8u but it is in `README-builds.html` and currently only seems to mention VS2010. We should probably do an update of the documentation, starting with a JDK-8176509 backport so it reflects the current status quo, especially after the move to Git. It's fine to leave this change out here though.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From andrew at openjdk.java.net  Wed May 11 17:36:05 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 11 May 2022 17:36:05 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v3]
In-Reply-To: <TUHEl-DYDw7dDzcL-jyeDwApEH5NgwPcsu-NOg8VNEU=.2a97ca43-de5a-46e4-83b2-10b2f4138ac2@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
 <TUHEl-DYDw7dDzcL-jyeDwApEH5NgwPcsu-NOg8VNEU=.2a97ca43-de5a-46e4-83b2-10b2f4138ac2@github.com>
Message-ID: <YPFzrEEBlyeTZPp3NDMrTyms3WYFF9tLSishqYZ5FFE=.d32be00b-3387-4f5f-9eee-bd0cf89d0e49@github.com>

On Wed, 11 May 2022 14:03:16 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> [JDK-8221988](https://bugs.openjdk.java.net/browse/JDK-8221988) labelled with jdk8u-fix-request

Approved.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From phh at openjdk.java.net  Wed May 11 23:43:59 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Wed, 11 May 2022 23:43:59 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
Message-ID: <a2RgPIsIKtNbrAM_yQ3BJbpUNPCmrJ5SkWPYrDDEqv4=.0d0d0c17-b8fa-4d2f-8b96-a467140aebec@github.com>

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

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

Clean backport net of file location. Lgtm.

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

Marked as reviewed by phh (Reviewer).

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

From duke at openjdk.java.net  Thu May 12 05:30:59 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Thu, 12 May 2022 05:30:59 GMT
Subject: [jdk8u-dev] Integrated: 8221988: add possibility to build with Visual
 Studio 2019
In-Reply-To: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
Message-ID: <kb9dzK3OBTNQCzK2ucBydvmsJ5aXjN-P-QrJvbb_8Ws=.bd6fd18f-a5c4-4057-920c-3f98dc89dd52@github.com>

On Thu, 7 Apr 2022 19:03:44 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Hi!
> 
> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. **WARNING**: the patch DOES NOT enable the building with MSVS2019 toolkit, that requires 5-6 more backports. The patch ONLY adds recognition of MSVS2019 to the build system.
> 
> The 11u patch applied with the following changes:
> 
> - changes to absent documentation files skipped
> - resolved baseline conflicts toolchain_windows.m4
> - valid MSVS versions were ascending sorted
> 
> Verification: `bash configure` under VS2019 prompt.
> 
> Regression:
> 
> - VS2017 full build (both 64/32-bit): ok
> - VS2015 full build: ok (requires --with-extra-cflags='/EHsc /wd4091' --with-extra-cxxflags='/EHsc /wd4091')
> - VS2013 full build: ok
> - VS2012 full build: ok
> - VS2010 full build: ok
> 
> @RealCLanger @mdoerr if you take a look at this I will be very grateful

This pull request has now been integrated.

Changeset: 51f69d91
Author:    Alexey Pavlyutkin <apavlyutkin at azul.com>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/51f69d9125e72adaf05fbd04a5ac17a9d2f6c6a0
Stats:     227 lines in 2 files changed: 223 ins; 0 del; 4 mod

8221988: add possibility to build with Visual Studio 2019

Reviewed-by: sgehwolf, andrew
Backport-of: f2240cc5b1f6e82c3d36551f36cd22916c1772bd

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From zgu at openjdk.java.net  Thu May 12 12:38:50 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 12 May 2022 12:38:50 GMT
Subject: [jdk8u-dev] RFR: 8260589: Crash in
 JfrTraceIdLoadBarrier::load(_jclass*)
In-Reply-To: <s3gnxE6q7VA8DMcUl6HeLBjf0La8dw6-a9mkE45tC18=.ec1f7e5b-eb11-4dc0-b593-019baa76ea28@github.com>
References: <s3gnxE6q7VA8DMcUl6HeLBjf0La8dw6-a9mkE45tC18=.ec1f7e5b-eb11-4dc0-b593-019baa76ea28@github.com>
Message-ID: <k_rP4U56HKyo0sIeWp31Z2LvmDpOcx7yien7zxiws_Y=.4bdc1f26-4756-4f24-989d-fd74d9c8426f@github.com>

On Mon, 18 Apr 2022 04:09:21 GMT, Long Yang <duke at openjdk.java.net> wrote:

> Hi!
> 
> Please review the backport of JDK-8260589 to 8u.
> This crash problem is easy to reproduce, so I feel it is necessary to backport it to 8u.
> 
> 3 months ago, I launched webrev and it has been reviewed by Zhengyu Gu ([the review mail link](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-March/014715.html)), thanks a lot to Zhengyu and Mario.
> Recently, I learned that the review method of 8u was changed to github, so I re-launched it in the new way.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8260589
> 11u commit: https://github.com/openjdk/jdk11u-dev/commit/1d204c554ffe969567161cc05992486ff47d346d
> Test: jdk/test/jdk/jfr/jvm/TestPrimitiveClasses.java passed.
> 
> Due to the differences between JFR in 11u and 17, Denghui made some changes when backporting this fix to 11u. 
> Denghui's changes also apply to 8u, so I directly quote Denghui's list here. (4 in total)
> 1. use MaxJfrEventId + 101 instead of LAST_TYPE_ID + 1 as the klass id of void.class
> 2. jdk 11 doesn't support jfr streaming, so I removed the call `JfrTraceIdEpoch::set_changed_tag_state()` in `load_primitive`
> 3. the Class in jdk 11 doesn't have the field 'hidden', so I removed `writer->write<bool>(false);` in `write_primitive`
> 4. there are many differences in the API of JfrTraceId between 11u and tip
> 
> In addition to the above differences, I also make supplementary explanations for the modifications I made.
> 1. The static global variable clear_artifacts in 11u was introduced by the bugfix https://bugs.openjdk.java.net/browse/JDK-8231081, but this fix has not been backported to 8u, so I removed the code related to clear_artifacts. In 8u, the metadata of the primitive types will be written into the previous chunk on every chunk rotation.
> 2. In 11u, _artifacts and _class_unload are static global variables, but in 8u, they are static member variables of JfrTypeSet, so I also made necessary changes to the functions that use these two variables.
> 
> Thanks

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/36

From duke at openjdk.java.net  Thu May 12 13:21:09 2022
From: duke at openjdk.java.net (Martijn Verburg)
Date: Thu, 12 May 2022 13:21:09 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v3]
In-Reply-To: <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
Message-ID: <As_riCLFewaTlDrRtq3X5CqMrDk3-kKP9ttaLzElT-A=.f5257c29-eac8-410e-9108-5766ff7d701a@github.com>

On Fri, 8 Apr 2022 17:46:57 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. **WARNING**: the patch DOES NOT enable the building with MSVS2019 toolkit, that requires 5-6 more backports. The patch ONLY adds recognition of MSVS2019 to the build system.
>> 
>> The 11u patch applied with the following changes:
>> 
>> - changes to absent documentation files skipped
>> - resolved baseline conflicts toolchain_windows.m4
>> - valid MSVS versions were ascending sorted
>> 
>> Verification: `bash configure` under VS2019 prompt.
>> 
>> Regression:
>> 
>> - VS2017 full build (both 64/32-bit): ok
>> - VS2015 full build: ok (requires --with-extra-cflags='/EHsc /wd4091' --with-extra-cxxflags='/EHsc /wd4091')
>> - VS2013 full build: ok
>> - VS2012 full build: ok
>> - VS2010 full build: ok
>> 
>> @RealCLanger @mdoerr if you take a look at this I will be very grateful
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rearrange valid VS versions

Seemed OK with our internal testing FWIW - sorry to be late to the party
here!

Cheers,
Martijn


On Thu, 12 May 2022 at 06:28, openjdk[bot] ***@***.***> wrote:

> @yan-too <https://github.com/yan-too> @apavlyutkin
> <https://github.com/apavlyutkin> Pushed as commit 51f69d9
> <https://github.com/openjdk/jdk8u-dev/commit/51f69d9125e72adaf05fbd04a5ac17a9d2f6c6a0>
> .
>
> ?? You may see a message that your pull request was closed with unmerged
> commits. This can be safely ignored.
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk8u-dev/pull/33#issuecomment-1124544511>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AABME2AJONMPQ3Z656Y3AOTVJSJGRANCNFSM5S2KGB4Q>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From duke at openjdk.java.net  Thu May 12 14:46:04 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Thu, 12 May 2022 14:46:04 GMT
Subject: [jdk8u-dev] Withdrawn: 8256722: handle VC++:1927 VS2019 in
 abstract_vm_version
In-Reply-To: <4iMO_KW4vtclo99ZkML4OxhBkdO5HK0dFGxjOLua06s=.3cff5a83-24e1-451d-8e9c-e6b0311e67eb@github.com>
References: <4iMO_KW4vtclo99ZkML4OxhBkdO5HK0dFGxjOLua06s=.3cff5a83-24e1-451d-8e9c-e6b0311e67eb@github.com>
Message-ID: <ntqxE131FjTfHtoJNPe_WdOGt1q1yZ1HxaIOC_IjADk=.5d94bde9-2102-4b26-904e-59188b62a324@github.com>

On Fri, 8 Apr 2022 09:41:57 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Hi!
> 
> Here is the backport of 8256722 that extends the list recognizable VC++ compiler versions for VS2019. The patch from 11u applied cleanly except the path shuffling:
> 
> src/hotspot/share/runtime/abstract_vm_version.cpp -> hotspot/src/share/vm/runtime/vm_version.cpp

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/34

From phh at openjdk.java.net  Thu May 12 16:01:16 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 12 May 2022 16:01:16 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
Message-ID: <KDcs5BvAy3Qm_fST_A2d5ca595mcN6-QhlCalCKGqt0=.4c207889-8aa0-4b87-aacf-16baff7c2417@github.com>

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

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

Passes java.util.concurrent jtreg tests.

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

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

From phh at openjdk.java.net  Thu May 12 17:41:01 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 12 May 2022 17:41:01 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
Message-ID: <jp4s5r95k-wAOSy0slhBpcfz5C9zpD98Decbs4ls8og=.aeac3617-7213-4ad0-943c-0dd27fdc2d06@github.com>

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

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

I'll sponsor this backport. Waiting for maintainer approval (jdk8u-fix-yes tag). See https://wiki.openjdk.java.net/display/jdk8u/Main for details.

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

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

From andrew at openjdk.java.net  Thu May 12 17:57:47 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 12 May 2022 17:57:47 GMT
Subject: [jdk8u-dev] RFR: 8281814: Debuginfo.diz contains redundant build
 path after backport JDK-8025936
In-Reply-To: <aHbBg4hcSAzhifdPCdsEoeHhIwB9nqJpFyO8EKA38G8=.688df3c7-306f-4eaf-9d61-e98ff54c9475@github.com>
References: <aHbBg4hcSAzhifdPCdsEoeHhIwB9nqJpFyO8EKA38G8=.688df3c7-306f-4eaf-9d61-e98ff54c9475@github.com>
Message-ID: <s2afCVwsOhE5uD0UZKOV8UL9g3gUfFVIENNeKd3SkX0=.98735be1-66a9-43e9-bfc7-4edb896801f1@github.com>

On Wed, 30 Mar 2022 07:45:08 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport 8035134 to fix debuginfo regression, introduced by [JDK-8025936](https://bugs.openjdk.java.net/browse/JDK-8025936).
> As discussed on [JDK-8281814](https://bugs.openjdk.java.net/browse/JDK-8281814), we cannot see the details of the original patch.
> It is only a different context, no risk.
> 
> Testing: worked correctly after patch.

This commit seems to have [broken the Mac OS build](https://github.com/gnu-andrew/jdk8u-dev/runs/5995961170?check_suite_focus=true)


gmake[2]: *** [lib/CoreLibraries.gmk:109: /Users/runner/work/jdk8u-dev/jdk8u-dev/jdk/build/macos-x64/jdk/objs/libverify/libverify.diz] Error 12
zip error: Nothing to do! (/Users/runner/work/jdk8u-dev/jdk8u-dev/jdk/build/macos-x64/jdk/objs/libverify/libverify.diz)


I'm guessing there is now no argument to `zip`. I'm going to look if there is a further follow-up commit in later JDKs.

@dongbohe while this one looks to have gone in before GHA support was added, and so missed a run on MacOS run, can you make sure you have actions enabled for future PRs? Thanks.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/26

From sgehwolf at openjdk.java.net  Thu May 12 18:43:46 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 18:43:46 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
Message-ID: <QCQg7KlhetYqnhjptw0IYTJy9X6h_Y3LLHUtl0-43Gk=.3188d4c9-381e-43f5-b8a7-f9ee3af4073e@github.com>

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

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

This is not in 11u as far as I can see. It should go there first before going into 8.

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

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

From phh at openjdk.java.net  Thu May 12 19:41:08 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 12 May 2022 19:41:08 GMT
Subject: [jdk8u-dev] RFR: 8284620: CodeBuffer may leak _overflow_arena
In-Reply-To: <0_0B3Wbda4gVbRm3uG08U7LME-LsSx6BR8UCLcc_1R0=.aaa95d24-1947-409d-84a0-2361d507ef7d@github.com>
References: <0_0B3Wbda4gVbRm3uG08U7LME-LsSx6BR8UCLcc_1R0=.aaa95d24-1947-409d-84a0-2361d507ef7d@github.com>
Message-ID: <GW0Zfhb8xTJsT7RR9oiimuaKNXyPi97hEDoKy_gBVHg=.6712237d-ceff-4eb6-b6ec-f8f60726e1e4@github.com>

On Mon, 2 May 2022 12:32:21 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to backport this patch to 8u for fixing a memory leak.
> 
> The original patch does not apply cleanly due to context difference. However, the patch is small, easily resolved manually.
> 
> Test:
> 
> - [x]  hotspot_compiler

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/52

From zgu at openjdk.java.net  Thu May 12 19:46:44 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 12 May 2022 19:46:44 GMT
Subject: [jdk8u-dev] RFR: 8284620: CodeBuffer may leak _overflow_arena
In-Reply-To: <GW0Zfhb8xTJsT7RR9oiimuaKNXyPi97hEDoKy_gBVHg=.6712237d-ceff-4eb6-b6ec-f8f60726e1e4@github.com>
References: <0_0B3Wbda4gVbRm3uG08U7LME-LsSx6BR8UCLcc_1R0=.aaa95d24-1947-409d-84a0-2361d507ef7d@github.com>
 <GW0Zfhb8xTJsT7RR9oiimuaKNXyPi97hEDoKy_gBVHg=.6712237d-ceff-4eb6-b6ec-f8f60726e1e4@github.com>
Message-ID: <pkGQvNz26dBo1PwZBEL2GfM9JbTS56TjABD8KXsCDMY=.c3b5b991-c97d-4d4d-9926-74f8bdf97cdb@github.com>

On Thu, 12 May 2022 19:39:05 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> I would like to backport this patch to 8u for fixing a memory leak.
>> 
>> The original patch does not apply cleanly due to context difference. However, the patch is small, easily resolved manually.
>> 
>> Test:
>> 
>> - [x]  hotspot_compiler
>
> Lgtm.

Thanks for the review, @phohensee

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/52

From andrew at openjdk.java.net  Fri May 13 03:16:58 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Fri, 13 May 2022 03:16:58 GMT
Subject: [jdk8u-dev] RFR: 8281814: Debuginfo.diz contains redundant build
 path after backport JDK-8025936
In-Reply-To: <aHbBg4hcSAzhifdPCdsEoeHhIwB9nqJpFyO8EKA38G8=.688df3c7-306f-4eaf-9d61-e98ff54c9475@github.com>
References: <aHbBg4hcSAzhifdPCdsEoeHhIwB9nqJpFyO8EKA38G8=.688df3c7-306f-4eaf-9d61-e98ff54c9475@github.com>
Message-ID: <jsxmC1Gh67bp8A-GpdugnpikNb3sEwm0RWsJoC7Stgg=.2a34007f-41f6-4b0d-bb94-731a9d059972@github.com>

On Wed, 30 Mar 2022 07:45:08 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport 8035134 to fix debuginfo regression, introduced by [JDK-8025936](https://bugs.openjdk.java.net/browse/JDK-8025936).
> As discussed on [JDK-8281814](https://bugs.openjdk.java.net/browse/JDK-8281814), we cannot see the details of the original patch.
> It is only a different context, no risk.
> 
> Testing: worked correctly after patch.

It looks like it is largely reverted again in [this 11u commit](https://github.com/openjdk/jdk11u-dev/commit//a350f3bda730bc3276e#diff-805224b793cfe47bf6bebf62286f34adb363f0352a9dac3689825b823886e534L882). I'll look at backporting just the changes to that file, as the rest is intrusive or not relevant.

On Mac, `$1_DEBUGINFO_FILES` contains just a directory, `$$($1_OBJECT_DIR)/$$($1_BASENAME).dSYM` and so ends up empty when this is filtered out. That patch changes the MacOS setup of `$1_DEBUGINFO_FILES` to refer to files.

It's not clear to me why this `notdir` fix was applied in the first place. The `subst` change in the later commit was identified in [JDK-8281814](https://bugs.openjdk.java.net/browse/JDK-8281814) but not applied.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/26

From dongbohe at openjdk.java.net  Fri May 13 06:24:44 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Fri, 13 May 2022 06:24:44 GMT
Subject: [jdk8u-dev] RFR: 8281814: Debuginfo.diz contains redundant build
 path after backport JDK-8025936
In-Reply-To: <jsxmC1Gh67bp8A-GpdugnpikNb3sEwm0RWsJoC7Stgg=.2a34007f-41f6-4b0d-bb94-731a9d059972@github.com>
References: <aHbBg4hcSAzhifdPCdsEoeHhIwB9nqJpFyO8EKA38G8=.688df3c7-306f-4eaf-9d61-e98ff54c9475@github.com>
 <jsxmC1Gh67bp8A-GpdugnpikNb3sEwm0RWsJoC7Stgg=.2a34007f-41f6-4b0d-bb94-731a9d059972@github.com>
Message-ID: <KvhnWuHsR0HaO6SjOFYKqsPs8rD1N-F9yB9jYi9K77Y=.2e610ae5-3ac2-4c9c-b21c-9e64d33ba21b@github.com>

On Fri, 13 May 2022 03:12:55 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport 8035134 to fix debuginfo regression, introduced by [JDK-8025936](https://bugs.openjdk.java.net/browse/JDK-8025936).
>> As discussed on [JDK-8281814](https://bugs.openjdk.java.net/browse/JDK-8281814), we cannot see the details of the original patch.
>> It is only a different context, no risk.
>> 
>> Testing: worked correctly after patch.
>
> It looks like it is largely reverted again in [this 11u commit](https://github.com/openjdk/jdk11u-dev/commit//a350f3bda730bc3276e#diff-805224b793cfe47bf6bebf62286f34adb363f0352a9dac3689825b823886e534L882). I'll look at backporting just the changes to that file, as the rest is intrusive or not relevant.
> 
> On Mac, `$1_DEBUGINFO_FILES` contains just a directory, `$$($1_OBJECT_DIR)/$$($1_BASENAME).dSYM` and so ends up empty when this is filtered out. That patch changes the MacOS setup of `$1_DEBUGINFO_FILES` to refer to files.
> 
> It's not clear to me why this `notdir` fix was applied in the first place. The `subst` change in the later commit was identified in [JDK-8281814](https://bugs.openjdk.java.net/browse/JDK-8281814) but not applied.

@gnu-andrew I have enabled actions for future PRs and will make sure to pass pre-commit tests before submitting PRs. 

> It looks like it is largely reverted again in [this 11u commit](https://github.com/openjdk/jdk11u-dev/commit//a350f3bda730bc3276e#diff-805224b793cfe47bf6bebf62286f34adb363f0352a9dac3689825b823886e534L882). I'll look at backporting just the changes to that file, as the rest is intrusive or not relevant.

thanks for looking into this.

> It's not clear to me why this `notdir` fix was applied in the first place. The `subst` change in the later commit was identified in [JDK-8281814](https://bugs.openjdk.java.net/browse/JDK-8281814) but not applied.

>From [Contribute to jdk8u](https://wiki.openjdk.java.net/display/jdk8u/Main), it is recommended to use the patch from the repository of the JDK version closest to 8u to minimise changes, so I used `notdir` change from the earlier commit to fix the problem.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/26

From duke at openjdk.java.net  Fri May 13 08:47:16 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Fri, 13 May 2022 08:47:16 GMT
Subject: [jdk8u-dev] RFR: 8197859: VS2017 Complains about UINTPTR_MAX
 definition in globalDefinitions_VisCPP.hpp
Message-ID: <MGeIIf-W3hQOM7mbOpSh5zsO2NRca8WgMq7dH4c44V4=.cc25e5ed-7091-475f-8c63-4d9527095c5b@github.com>

Hi! Please review another backport from MSVS2019 seria. This one fixes type declarations made by globalDefinitions_VisCPP.hpp. The patch from 11u applied with the following changes:

- inttypes.h is included conditionally under `_MSC_VER >= 1800` because the header was introduced only in MSVS 2013 but we have to keep support of the earlier MSVS versions 
- the declarations made by inttypes.h are not just removed but quoted with `_MSC_VER < 1800`
- common\autoconf\generated-configure.sh is regenerated to add MSVS2019 recognition (I forgot to do that in https://github.com/openjdk/jdk8u-dev/pull/33)

Verification: 2019 build (both 32/64) now fails with 

ad_x86_64_pipeline.obj : error LNK2011: precompiled object not linked in; image may not run
jvm.dll : fatal error LNK1120: 1 unresolved externals

error (to be fixed by backport of 8043492)

Regression: 2017/2013/2012/2010 full build - ok

@kimbarrett @dholmes-ora if you took a look at that it would be very much appreciated

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

Commit messages:
 - fixes trailing whitespaces
 - Backport b8ab854bdcf625772e965a5e476e0a9db1b91f3f

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/58/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=58&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8197859
  Stats: 11688 lines in 2 files changed: 2656 ins; 512 del; 8520 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/58.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/58/head:pull/58

PR: https://git.openjdk.java.net/jdk8u-dev/pull/58

From scrater at microsoft.com  Fri May 13 14:08:58 2022
From: scrater at microsoft.com (Stephanie Crater)
Date: Fri, 13 May 2022 14:08:58 +0000
Subject: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
In-Reply-To: <7876ea4d-e923-91d5-039f-0433863870b4@bell-sw.com>
References: <DM6PR21MB161059D978862BE722863B9AA1FD9@DM6PR21MB1610.namprd21.prod.outlook.com>
 <7876ea4d-e923-91d5-039f-0433863870b4@bell-sw.com>
Message-ID: <DM6PR21MB161046CA8E4E4CCDEA346ACDA1CA9@DM6PR21MB1610.namprd21.prod.outlook.com>

Hi Aleksei and Andrew,

This was some work done by Microsoft largely based off the Alpine project's port [1] to fulfill the needs of Azure App Service. I also pulled in some of the initial changes to OpenJDK 16 in JEP 386 [2] (namely, detecting the C library and defining MUSL_LIBC), as the Alpine project's port modified jdk8 to support Alpine/musl libc only at the expense of other operating systems/C libraries.

I would be happy to open an initial PR on the jdk8u-dev repo to discuss the particulars and apply refactoring from feedback and advice.

Thanks,
Stephanie

[1] openjdk8 ? community - aports - Alpine packages build scripts (alpinelinux.org)<https://git.alpinelinux.org/aports/tree/community/openjdk8>
[2] 8247589: Implementation of Alpine Linux/x64 Port ? openjdk/jdk16u at 63009f9 (github.com)<https://github.com/openjdk/jdk16u/commit/63009f90ec7df053c936226663b463b8584364a9>


From: Aleksei Voitylov <aleksei.voitylov at bell-sw.com>
Date: Thursday, May 5, 2022 at 10:32 AM
To: Stephanie Crater <scrater at microsoft.com>, jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
Hi Stephanie,

when briefly looking through the changed filenames I stumbled upon
cpu/ppc/vm, os_cpu/linux_ppc/vm and couldn't recollect having to touch
these directories in JEP 386. So, I wanted to ask a question:

Is this a backport of the set of changes that were committed upstream to
OpenJDK 16 in JEP 386 (or a backport from 11u backports I recently did)?
Or is this some original work Microsoft has done for 8u shared code and
PPC in particular?

Thanks,

-Aleksei

On 28/04/2022 20:16, Stephanie Crater wrote:
> Hi,
>
> Would the community be open to a port of JEP 386: Alpine Linux Port [1]/JDK-8247589 [2] to OpenJDK jdk8u? A backport of JDK-8247589 to 11u has recently been integrated by BellSoft, and many OpenJDK vendors (BellSoft Liberica, Azul Zulu, Amazon Corretto) provide a jdk8 for Alpine Linux. We believe there is sufficient user demand for Alpine/musl support on jdk8u, but would be interested in the opinions of other vendors on this as well.
>
> Microsoft is part of the Eclipse Adoptium Working Group and has recently trialed a patch which was applied to the 8u322 tag on the jdk8u source tree (for Eclipse Temurin binary production)[3]. That 8u322 based binary passes builds on all platforms (i.e. No regressions on other platforms) and the AQAVit test suite. The Eclipse Temurin Compliance group also reported that the TCK passed.
>
> We would be willing to maintain Alpine Linux in jdk8u but would prefer that there is broad support. Please let me know what you think or if there are any concerns you may have regarding the proposal of this backport.
>
> Thanks,
> Stephanie
>
> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fjeps%2F386&amp;data=05%7C01%7Cscrater%40microsoft.com%7C57bae90fe28148c90fb908da2ea40693%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637873579263062324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=wI5GWxdBIt01sJ3tf%2B5JxnC%2FXuqM9l12hlMFAyoji4c%3D&amp;reserved=0
> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247589&amp;data=05%7C01%7Cscrater%40microsoft.com%7C57bae90fe28148c90fb908da2ea40693%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637873579263062324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=uqjYEoxOct5fWt%2FikgilUT6e2w6%2FcDZH2HTbgCF3vpE%3D&amp;reserved=0
> [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadoptium%2Fjdk8u%2Fpull%2F9&amp;data=05%7C01%7Cscrater%40microsoft.com%7C57bae90fe28148c90fb908da2ea40693%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637873579263062324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=kq0F9i35CSD5A6Y0b7%2BKp3fjAavQ4kL6lvDDS6%2BLq9I%3D&amp;reserved=0
>

From dalibor.topic at oracle.com  Fri May 13 14:58:25 2022
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 13 May 2022 16:58:25 +0200
Subject: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
In-Reply-To: <DM6PR21MB161046CA8E4E4CCDEA346ACDA1CA9@DM6PR21MB1610.namprd21.prod.outlook.com>
References: <DM6PR21MB161059D978862BE722863B9AA1FD9@DM6PR21MB1610.namprd21.prod.outlook.com>
 <7876ea4d-e923-91d5-039f-0433863870b4@bell-sw.com>
 <DM6PR21MB161046CA8E4E4CCDEA346ACDA1CA9@DM6PR21MB1610.namprd21.prod.outlook.com>
Message-ID: <739d096c-7245-0723-17f0-e96b8122de00@oracle.com>



On 13.05.2022 16:08, Stephanie Crater wrote:
> Hi Aleksei and Andrew,
> 
> This was some work done by Microsoft largely based off the Alpine project's port [1] to fulfill the needs of Azure App Service. I also pulled in some of the initial changes to OpenJDK 16 in JEP 386 [2] (namely, detecting the C library and defining MUSL_LIBC), as the Alpine project's port modified jdk8 to support Alpine/musl libc only at the expense of other operating systems/C libraries.
> 
> I would be happy to open an initial PR on the jdk8u-dev repo to discuss the particulars and apply refactoring from feedback and advice.

Hi Stephanie,

unfortunately, if the port is based on third party changes from outside 
of the OpenJDK Community, like Alpine, Eclipse, etc., then their authors 
would need to have an OCA on file first, and contribute those changes 
themselves, before a port based on such changes could be integrated.

cheers,
dalibor topic

> 
> Thanks,
> Stephanie
> 
> [1] openjdk8 ? community - aports - Alpine packages build scripts (alpinelinux.org)<https://git.alpinelinux.org/aports/tree/community/openjdk8>
> [2] 8247589: Implementation of Alpine Linux/x64 Port ? openjdk/jdk16u at 63009f9 (github.com)<https://github.com/openjdk/jdk16u/commit/63009f90ec7df053c936226663b463b8584364a9>
> 
> 
> From: Aleksei Voitylov <aleksei.voitylov at bell-sw.com>
> Date: Thursday, May 5, 2022 at 10:32 AM
> To: Stephanie Crater <scrater at microsoft.com>, jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
> Subject: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
> Hi Stephanie,
> 
> when briefly looking through the changed filenames I stumbled upon
> cpu/ppc/vm, os_cpu/linux_ppc/vm and couldn't recollect having to touch
> these directories in JEP 386. So, I wanted to ask a question:
> 
> Is this a backport of the set of changes that were committed upstream to
> OpenJDK 16 in JEP 386 (or a backport from 11u backports I recently did)?
> Or is this some original work Microsoft has done for 8u shared code and
> PPC in particular?
> 
> Thanks,
> 
> -Aleksei
> 
> On 28/04/2022 20:16, Stephanie Crater wrote:
>> Hi,
>>
>> Would the community be open to a port of JEP 386: Alpine Linux Port [1]/JDK-8247589 [2] to OpenJDK jdk8u? A backport of JDK-8247589 to 11u has recently been integrated by BellSoft, and many OpenJDK vendors (BellSoft Liberica, Azul Zulu, Amazon Corretto) provide a jdk8 for Alpine Linux. We believe there is sufficient user demand for Alpine/musl support on jdk8u, but would be interested in the opinions of other vendors on this as well.
>>
>> Microsoft is part of the Eclipse Adoptium Working Group and has recently trialed a patch which was applied to the 8u322 tag on the jdk8u source tree (for Eclipse Temurin binary production)[3]. That 8u322 based binary passes builds on all platforms (i.e. No regressions on other platforms) and the AQAVit test suite. The Eclipse Temurin Compliance group also reported that the TCK passed.
>>
>> We would be willing to maintain Alpine Linux in jdk8u but would prefer that there is broad support. Please let me know what you think or if there are any concerns you may have regarding the proposal of this backport.
>>
>> Thanks,
>> Stephanie
>>
>> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fjeps%2F386&amp;data=05%7C01%7Cscrater%40microsoft.com%7C57bae90fe28148c90fb908da2ea40693%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637873579263062324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=wI5GWxdBIt01sJ3tf%2B5JxnC%2FXuqM9l12hlMFAyoji4c%3D&amp;reserved=0
>> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247589&amp;data=05%7C01%7Cscrater%40microsoft.com%7C57bae90fe28148c90fb908da2ea40693%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637873579263062324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=uqjYEoxOct5fWt%2FikgilUT6e2w6%2FcDZH2HTbgCF3vpE%3D&amp;reserved=0
>> [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadoptium%2Fjdk8u%2Fpull%2F9&amp;data=05%7C01%7Cscrater%40microsoft.com%7C57bae90fe28148c90fb908da2ea40693%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637873579263062324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=kq0F9i35CSD5A6Y0b7%2BKp3fjAavQ4kL6lvDDS6%2BLq9I%3D&amp;reserved=0
>>

-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>

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


From andrew at openjdk.java.net  Fri May 13 16:25:46 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Fri, 13 May 2022 16:25:46 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows
In-Reply-To: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
Message-ID: <eAS6pbsOMrS4DWyPeL_v5iuWQ3pFpD2t5QUkEKzcZjU=.d8e783f1-8304-471c-b93e-073b38192bcf@github.com>

On Wed, 20 Apr 2022 21:01:34 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> A fix to 8u-only Windows-specific problem with -XX:+PrintFlags* output.
> 
> Problem description on Stack Overflow by Andrei Pangin: https://stackoverflow.com/a/63309395
> 
> The problem was fixed in jdk9 as part of [JDK-8042893](https://bugs.openjdk.java.net/browse/JDK-8042893), but this [jdk9 change](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15) doesn't look like a good candidate for the 8u backport according to [8u Best Practices](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html). Still the problem manifests itself as a customer-visible bug on Windows because people do use -XX:+PrintFlagsFinal to find out the actual flags picked up by JVM and can be confused by unexpected zeros in the output. Proposed patch cherry-picks the minimal change from [JDK-8042893 commit](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15#l53.1).
> 
> Mailing list review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-February/014532.html
> 
> Testing:
> 
>  - [x] regression test is included with the proposed patch
>  - [x] checked that it builds on Windows 64-bit and 32-bit on VS2017 and VS2010
>  - [x] ran jtreg:hotspot/test/runtime on Windows and Linux

This mostly matches the changes to this file in JDK-8042893, but it doesn't remove [the pragma](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15#l53.7)

Can we include that change as well to make sure the code is now compiling without warnings?

Also, the PR needs to be rebased anyway to fix the GHA run on Linux (bad dependency issue now fixed by [JDK-8284772](https://bugs.openjdk.java.net/browse/JDK-8284772). The Mac failure is more complicated (see #26) but is at least compiling the code before failing. Despite the title, this changes code shared by all platforms.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/45

From akasko at openjdk.java.net  Fri May 13 17:18:56 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Fri, 13 May 2022 17:18:56 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows
In-Reply-To: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
Message-ID: <HZb4Pq-X_z8ZPsjPTVAQSArVxOg0Deh9e-0B9npJVUA=.49744634-9bc2-4225-bff6-b0d2295962b0@github.com>

On Wed, 20 Apr 2022 21:01:34 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> A fix to 8u-only Windows-specific problem with -XX:+PrintFlags* output.
> 
> Problem description on Stack Overflow by Andrei Pangin: https://stackoverflow.com/a/63309395
> 
> The problem was fixed in jdk9 as part of [JDK-8042893](https://bugs.openjdk.java.net/browse/JDK-8042893), but this [jdk9 change](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15) doesn't look like a good candidate for the 8u backport according to [8u Best Practices](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html). Still the problem manifests itself as a customer-visible bug on Windows because people do use -XX:+PrintFlagsFinal to find out the actual flags picked up by JVM and can be confused by unexpected zeros in the output. Proposed patch cherry-picks the minimal change from [JDK-8042893 commit](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15#l53.1).
> 
> Mailing list review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-February/014532.html
> 
> Testing:
> 
>  - [x] regression test is included with the proposed patch
>  - [x] checked that it builds on Windows 64-bit and 32-bit on VS2017 and VS2010
>  - [x] ran jtreg:hotspot/test/runtime on Windows and Linux

Would it be better if I add a `PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC` change as a separate backport?

I understand that it is a part of the same original change, just the motivation behind the change is completely different from the format strings change that are included now. I am fine with doing it either way, just wanted to point out that the inclusion of pragma here may be confusing.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/45

From akasko at openjdk.java.net  Fri May 13 17:38:41 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Fri, 13 May 2022 17:38:41 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows [v2]
In-Reply-To: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
Message-ID: <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>

> A fix to 8u-only Windows-specific problem with -XX:+PrintFlags* output.
> 
> Problem description on Stack Overflow by Andrei Pangin: https://stackoverflow.com/a/63309395
> 
> The problem was fixed in jdk9 as part of [JDK-8042893](https://bugs.openjdk.java.net/browse/JDK-8042893), but this [jdk9 change](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15) doesn't look like a good candidate for the 8u backport according to [8u Best Practices](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html). Still the problem manifests itself as a customer-visible bug on Windows because people do use -XX:+PrintFlagsFinal to find out the actual flags picked up by JVM and can be confused by unexpected zeros in the output. Proposed patch cherry-picks the minimal change from [JDK-8042893 commit](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15#l53.1).
> 
> Mailing list review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-February/014532.html
> 
> Testing:
> 
>  - [x] regression test is included with the proposed patch
>  - [x] checked that it builds on Windows 64-bit and 32-bit on VS2017 and VS2010
>  - [x] ran jtreg:hotspot/test/runtime on Windows and Linux

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

  8280963: Incorrect PrintFlags formatting on Windows

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/45/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/45/files/5ef280c4..a312b2ce

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

  Stats: 3887 lines in 74 files changed: 2718 ins; 731 del; 438 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/45.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/45/head:pull/45

PR: https://git.openjdk.java.net/jdk8u-dev/pull/45

From phh at openjdk.java.net  Fri May 13 19:36:45 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Fri, 13 May 2022 19:36:45 GMT
Subject: [jdk8u-dev] RFR: 8168926: C2: Bytecode escape analyzer crashes due
 to stack overflow
In-Reply-To: <zr61DLQuPvxa6-asQ_efIbsoZ_VZyFocEb3UcIUHqT0=.364c0a8d-1b23-46a0-9798-023d803c0779@github.com>
References: <zr61DLQuPvxa6-asQ_efIbsoZ_VZyFocEb3UcIUHqT0=.364c0a8d-1b23-46a0-9798-023d803c0779@github.com>
Message-ID: <YIN4tMCPBr5gMZGEDx728oWcE40psXAZpfXSuTVxFCI=.b8b96a8a-fa36-42b4-9aae-89bc42fbd2ce@github.com>

On Thu, 5 May 2022 20:20:23 GMT, Joshua Cao <duke at openjdk.java.net> wrote:

> This is a clean backport of [8168926](https://bugs.openjdk.java.net/browse/JDK-8168926) from openjdk/jdk repository. Passing `make test`.

Waiting for jdk8u-fix-yes.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/53

From scrater at microsoft.com  Fri May 13 19:40:17 2022
From: scrater at microsoft.com (Stephanie Crater)
Date: Fri, 13 May 2022 19:40:17 +0000
Subject: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
In-Reply-To: <739d096c-7245-0723-17f0-e96b8122de00@oracle.com>
References: <DM6PR21MB161059D978862BE722863B9AA1FD9@DM6PR21MB1610.namprd21.prod.outlook.com>
 <7876ea4d-e923-91d5-039f-0433863870b4@bell-sw.com>
 <DM6PR21MB161046CA8E4E4CCDEA346ACDA1CA9@DM6PR21MB1610.namprd21.prod.outlook.com>
 <739d096c-7245-0723-17f0-e96b8122de00@oracle.com>
Message-ID: <DM6PR21MB161030A818CCDD4CAD1C6E36A1CA9@DM6PR21MB1610.namprd21.prod.outlook.com>

Thanks Dalibor for pointing that out ? I?ll reach out to those authors.

Best,
Stephanie

From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Dalibor Topic <dalibor.topic at oracle.com>
Date: Friday, May 13, 2022 at 10:59 AM
To: jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject: Re: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
[You don't often get email from dalibor.topic at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification.]<https://aka.ms/LearnAboutSenderIdentification.%5d>

On 13.05.2022 16:08, Stephanie Crater wrote:
> Hi Aleksei and Andrew,
>
> This was some work done by Microsoft largely based off the Alpine project's port [1] to fulfill the needs of Azure App Service. I also pulled in some of the initial changes to OpenJDK 16 in JEP 386 [2] (namely, detecting the C library and defining MUSL_LIBC), as the Alpine project's port modified jdk8 to support Alpine/musl libc only at the expense of other operating systems/C libraries.
>
> I would be happy to open an initial PR on the jdk8u-dev repo to discuss the particulars and apply refactoring from feedback and advice.

Hi Stephanie,

unfortunately, if the port is based on third party changes from outside
of the OpenJDK Community, like Alpine, Eclipse, etc., then their authors
would need to have an OCA on file first, and contribute those changes
themselves, before a port based on such changes could be integrated.

cheers,
dalibor topic

>
> Thanks,
> Stephanie
>
> [1] openjdk8 ? community - aports - Alpine packages build scripts (alpinelinux.org)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.alpinelinux.org%2Faports%2Ftree%2Fcommunity%2Fopenjdk8&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422783062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=BX6lU%2FoHoTpYpG0VYgYb9VvJsAQP%2BLjOpmQSJdfDvf4%3D&amp;reserved=0>
> [2] 8247589: Implementation of Alpine Linux/x64 Port ? openjdk/jdk16u at 63009f9 (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk16u%2Fcommit%2F63009f90ec7df053c936226663b463b8584364a9&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422933052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TqM12aRlvAGaQm9V2W3bEj1Pskp9ikCMcJ%2FsTEhAPww%3D&amp;reserved=0>
>
>
> From: Aleksei Voitylov <aleksei.voitylov at bell-sw.com>
> Date: Thursday, May 5, 2022 at 10:32 AM
> To: Stephanie Crater <scrater at microsoft.com>, jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
> Subject: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
> Hi Stephanie,
>
> when briefly looking through the changed filenames I stumbled upon
> cpu/ppc/vm, os_cpu/linux_ppc/vm and couldn't recollect having to touch
> these directories in JEP 386. So, I wanted to ask a question:
>
> Is this a backport of the set of changes that were committed upstream to
> OpenJDK 16 in JEP 386 (or a backport from 11u backports I recently did)?
> Or is this some original work Microsoft has done for 8u shared code and
> PPC in particular?
>
> Thanks,
>
> -Aleksei
>
> On 28/04/2022 20:16, Stephanie Crater wrote:
>> Hi,
>>
>> Would the community be open to a port of JEP 386: Alpine Linux Port [1]/JDK-8247589 [2] to OpenJDK jdk8u? A backport of JDK-8247589 to 11u has recently been integrated by BellSoft, and many OpenJDK vendors (BellSoft Liberica, Azul Zulu, Amazon Corretto) provide a jdk8 for Alpine Linux. We believe there is sufficient user demand for Alpine/musl support on jdk8u, but would be interested in the opinions of other vendors on this as well.
>>
>> Microsoft is part of the Eclipse Adoptium Working Group and has recently trialed a patch which was applied to the 8u322 tag on the jdk8u source tree (for Eclipse Temurin binary production)[3]. That 8u322 based binary passes builds on all platforms (i.e. No regressions on other platforms) and the AQAVit test suite. The Eclipse Temurin Compliance group also reported that the TCK passed.
>>
>> We would be willing to maintain Alpine Linux in jdk8u but would prefer that there is broad support. Please let me know what you think or if there are any concerns you may have regarding the proposal of this backport.
>>
>> Thanks,
>> Stephanie
>>
>> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fjeps%2F386&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422933052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=P%2B9KjuKup6z4RDtczW9TROMshr2FXugfdTATi92Ye6g%3D&amp;reserved=0
>> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247589&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422933052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=DG%2FaoE0ELmWzjWIjijtqSOLdjwaDCkI6ebZAnlynLtw%3D&amp;reserved=0
>> [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadoptium%2Fjdk8u%2Fpull%2F9&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422933052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=jTgHcAT%2F%2BOOSSKJOhnTi9fW6fu93NW8kIBzgM2me6Qk%3D&amp;reserved=0
>>

--
<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.oracle.com%2F&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422933052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=AJVA1SS4OOm572zF9%2FbQnGv4jtgh%2FJxxd%2FmPUkPJLh4%3D&amp;reserved=0> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>

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

From serb at openjdk.java.net  Mon May 16 01:49:18 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 16 May 2022 01:49:18 GMT
Subject: [jdk8u-dev] RFR: 8285523: Improve test
 java/io/FileOutputStream/OpenNUL.java
Message-ID: <QU81rxZ40IsPmjhtSsPnClLVpCIKD9wQApFHp8zD7Go=.778efb23-a001-4433-9bec-cbf0a78288a6@github.com>

Hi all,
This pull request contains a backport of commit [f42631e3](https://github.com/openjdk/jdk/commit/f42631e354d4abf7994abd92aa5def6b2ceeab3a) from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository.
The commit being backported was authored by Sergey Bylokhov on 29 Apr 2022 and was reviewed by Andrew John Hughes and Brian Burkhalter.
Thanks!

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

Commit messages:
 - Backport f42631e354d4abf7994abd92aa5def6b2ceeab3a

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/59

From aleksei.voitylov at bell-sw.com  Mon May 16 12:19:38 2022
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Mon, 16 May 2022 15:19:38 +0300
Subject: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
In-Reply-To: <DM6PR21MB161030A818CCDD4CAD1C6E36A1CA9@DM6PR21MB1610.namprd21.prod.outlook.com>
References: <DM6PR21MB161059D978862BE722863B9AA1FD9@DM6PR21MB1610.namprd21.prod.outlook.com>
 <7876ea4d-e923-91d5-039f-0433863870b4@bell-sw.com>
 <DM6PR21MB161046CA8E4E4CCDEA346ACDA1CA9@DM6PR21MB1610.namprd21.prod.outlook.com>
 <739d096c-7245-0723-17f0-e96b8122de00@oracle.com>
 <DM6PR21MB161030A818CCDD4CAD1C6E36A1CA9@DM6PR21MB1610.namprd21.prod.outlook.com>
Message-ID: <c8a5d3bc-199b-b307-44c9-b6087bdb1bbf@bell-sw.com>

Stephanie,

If backporting JEP 386 to 8u is justifiable, I'd like to see a clean
backport of the exact set of changes made to upstream OpenJDK in JEP
386, without mixing in external contributions. Please refer to the full
list in 11u discussion. This will simplify maintenance.

If additional fixes are required for Alpine support, these should be
handled upstream first and not mixed into the backport now.

In the end, I could do 8u backports myself (now that support for Alpine
is in 11u OpenJDK code base and will appear in July 2022 release), but
please help find convincing evidence this is the right thing to do. I'm
torn on this since in my system of coordinates the justification used
for 11u doesn't outweight the risks of breaking something for an 8u
release which should be in deep maintenance. It may easily happen your
stats for 8u use on Alpine differ drastically from mine.

-Aleksei

On 13.05.2022 22:40, Stephanie Crater wrote:
> Thanks Dalibor for pointing that out ? I?ll reach out to those authors.
>
> Best,
> Stephanie
>
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Dalibor Topic <dalibor.topic at oracle.com>
> Date: Friday, May 13, 2022 at 10:59 AM
> To: jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
> Subject: Re: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
> [You don't often get email from dalibor.topic at oracle.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification.]<https://aka.ms/LearnAboutSenderIdentification.%5d>
>
> On 13.05.2022 16:08, Stephanie Crater wrote:
>> Hi Aleksei and Andrew,
>>
>> This was some work done by Microsoft largely based off the Alpine project's port [1] to fulfill the needs of Azure App Service. I also pulled in some of the initial changes to OpenJDK 16 in JEP 386 [2] (namely, detecting the C library and defining MUSL_LIBC), as the Alpine project's port modified jdk8 to support Alpine/musl libc only at the expense of other operating systems/C libraries.
>>
>> I would be happy to open an initial PR on the jdk8u-dev repo to discuss the particulars and apply refactoring from feedback and advice.
> Hi Stephanie,
>
> unfortunately, if the port is based on third party changes from outside
> of the OpenJDK Community, like Alpine, Eclipse, etc., then their authors
> would need to have an OCA on file first, and contribute those changes
> themselves, before a port based on such changes could be integrated.
>
> cheers,
> dalibor topic
>
>> Thanks,
>> Stephanie
>>
>> [1] openjdk8 ? community - aports - Alpine packages build scripts (alpinelinux.org)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.alpinelinux.org%2Faports%2Ftree%2Fcommunity%2Fopenjdk8&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422783062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=BX6lU%2FoHoTpYpG0VYgYb9VvJsAQP%2BLjOpmQSJdfDvf4%3D&amp;reserved=0>
>> [2] 8247589: Implementation of Alpine Linux/x64 Port ? openjdk/jdk16u at 63009f9 (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk16u%2Fcommit%2F63009f90ec7df053c936226663b463b8584364a9&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422933052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=TqM12aRlvAGaQm9V2W3bEj1Pskp9ikCMcJ%2FsTEhAPww%3D&amp;reserved=0>
>>
>>
>> From: Aleksei Voitylov <aleksei.voitylov at bell-sw.com>
>> Date: Thursday, May 5, 2022 at 10:32 AM
>> To: Stephanie Crater <scrater at microsoft.com>, jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
>> Subject: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
>> Hi Stephanie,
>>
>> when briefly looking through the changed filenames I stumbled upon
>> cpu/ppc/vm, os_cpu/linux_ppc/vm and couldn't recollect having to touch
>> these directories in JEP 386. So, I wanted to ask a question:
>>
>> Is this a backport of the set of changes that were committed upstream to
>> OpenJDK 16 in JEP 386 (or a backport from 11u backports I recently did)?
>> Or is this some original work Microsoft has done for 8u shared code and
>> PPC in particular?
>>
>> Thanks,
>>
>> -Aleksei
>>
>> On 28/04/2022 20:16, Stephanie Crater wrote:
>>> Hi,
>>>
>>> Would the community be open to a port of JEP 386: Alpine Linux Port [1]/JDK-8247589 [2] to OpenJDK jdk8u? A backport of JDK-8247589 to 11u has recently been integrated by BellSoft, and many OpenJDK vendors (BellSoft Liberica, Azul Zulu, Amazon Corretto) provide a jdk8 for Alpine Linux. We believe there is sufficient user demand for Alpine/musl support on jdk8u, but would be interested in the opinions of other vendors on this as well.
>>>
>>> Microsoft is part of the Eclipse Adoptium Working Group and has recently trialed a patch which was applied to the 8u322 tag on the jdk8u source tree (for Eclipse Temurin binary production)[3]. That 8u322 based binary passes builds on all platforms (i.e. No regressions on other platforms) and the AQAVit test suite. The Eclipse Temurin Compliance group also reported that the TCK passed.
>>>
>>> We would be willing to maintain Alpine Linux in jdk8u but would prefer that there is broad support. Please let me know what you think or if there are any concerns you may have regarding the proposal of this backport.
>>>
>>> Thanks,
>>> Stephanie
>>>
>>> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fjeps%2F386&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422933052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=P%2B9KjuKup6z4RDtczW9TROMshr2FXugfdTATi92Ye6g%3D&amp;reserved=0
>>> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247589&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422933052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=DG%2FaoE0ELmWzjWIjijtqSOLdjwaDCkI6ebZAnlynLtw%3D&amp;reserved=0
>>> [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fadoptium%2Fjdk8u%2Fpull%2F9&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422933052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=jTgHcAT%2F%2BOOSSKJOhnTi9fW6fu93NW8kIBzgM2me6Qk%3D&amp;reserved=0
>>>
> --
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.oracle.com%2F&amp;data=05%7C01%7Cscrater%40microsoft.com%7C7330d9e636bf4a2360c508da34f11c61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637880507422933052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=AJVA1SS4OOm572zF9%2FbQnGv4jtgh%2FJxxd%2FmPUkPJLh4%3D&amp;reserved=0> Dalibor Topic
> Consulting Product Manager
> Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
> <tel:+491737185961>
>
> Oracle Global Services Germany GmbH
> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
> Registergericht: Amtsgericht M?nchen, HRB 246209
> Gesch?ftsf?hrer: Ralf Herrmann


From duke at openjdk.java.net  Mon May 16 16:12:52 2022
From: duke at openjdk.java.net (duke)
Date: Mon, 16 May 2022 16:12:52 GMT
Subject: [jdk8u-dev] Withdrawn: 8235218: Minimal VM is broken after JDK-8173361
In-Reply-To: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
Message-ID: <Ynee_BkMbGhH3goESrdnA_2FZMUMfzT8gNi4DfZUTmE=.7d9ab25b-aa65-42fb-b7fa-cb0363a94c6f@github.com>

On Mon, 21 Mar 2022 06:51:21 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this as follow up of [JDK-8173361](https://bugs.openjdk.java.net/browse/JDK-8173361), only a different context.
> 
> Thanks,
> hedongbo

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/19

From duke at openjdk.java.net  Mon May 16 17:07:00 2022
From: duke at openjdk.java.net (Joshua Cao)
Date: Mon, 16 May 2022 17:07:00 GMT
Subject: [jdk8u-dev] Integrated: 8168926: C2: Bytecode escape analyzer crashes
 due to stack overflow
In-Reply-To: <zr61DLQuPvxa6-asQ_efIbsoZ_VZyFocEb3UcIUHqT0=.364c0a8d-1b23-46a0-9798-023d803c0779@github.com>
References: <zr61DLQuPvxa6-asQ_efIbsoZ_VZyFocEb3UcIUHqT0=.364c0a8d-1b23-46a0-9798-023d803c0779@github.com>
Message-ID: <AFBONj0MVN_p6ZgPSZNrdjo8Qxxy_Ymr-s0TImha9Pk=.fa70e28a-69e8-42b5-adc0-f3ccbc7e1ded@github.com>

On Thu, 5 May 2022 20:20:23 GMT, Joshua Cao <duke at openjdk.java.net> wrote:

> This is a clean backport of [8168926](https://bugs.openjdk.java.net/browse/JDK-8168926) from openjdk/jdk repository. Passing `make test`.

This pull request has now been integrated.

Changeset: 680b09c7
Author:    Joshua Cao <joshcao at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/680b09c7568fd3ba476e63c0dbca0a6301bf3d95
Stats:     35 lines in 2 files changed: 29 ins; 1 del; 5 mod

8168926: C2: Bytecode escape analyzer crashes due to stack overflow

Reviewed-by: phh

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/53

From darcy at openjdk.java.net  Tue May 17 03:20:52 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 17 May 2022 03:20:52 GMT
Subject: [jdk8u-ri] Integrated: JDK-8285497: Add system property for Java SE
 specification maintenance version
In-Reply-To: <THxDT63s1ZaEWmsoyBIdKUTRNS13iTkzbdrRlhZgf6s=.a2afda8b-519e-4e94-a7fa-61de280e229f@github.com>
References: <THxDT63s1ZaEWmsoyBIdKUTRNS13iTkzbdrRlhZgf6s=.a2afda8b-519e-4e94-a7fa-61de280e229f@github.com>
Message-ID: <VfE3fS9yFZCdGXUHOvJ7ec6fLESKmAFzxn291_InhYM=.93fe65a6-234c-4570-965c-11a74e8f834b@github.com>

On Fri, 6 May 2022 21:52:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Backport of change from JDK 19.

This pull request has now been integrated.

Changeset: 31a63ba5
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-ri/commit/31a63ba5f255e09349b3842984ac5bb3ad8e6c0b
Stats:     23 lines in 4 files changed: 20 ins; 0 del; 3 mod

8285497: Add system property for Java SE specification maintenance version

Reviewed-by: mchung, iris, aph

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/8

From dongbohe at openjdk.java.net  Tue May 17 04:02:55 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Tue, 17 May 2022 04:02:55 GMT
Subject: [jdk8u-dev] RFR: 8281814: Debuginfo.diz contains redundant build
 path after backport JDK-8025936
In-Reply-To: <jsxmC1Gh67bp8A-GpdugnpikNb3sEwm0RWsJoC7Stgg=.2a34007f-41f6-4b0d-bb94-731a9d059972@github.com>
References: <aHbBg4hcSAzhifdPCdsEoeHhIwB9nqJpFyO8EKA38G8=.688df3c7-306f-4eaf-9d61-e98ff54c9475@github.com>
 <jsxmC1Gh67bp8A-GpdugnpikNb3sEwm0RWsJoC7Stgg=.2a34007f-41f6-4b0d-bb94-731a9d059972@github.com>
Message-ID: <7qINRcPYTlVX4KWtufBdb3NkWGOxC8puPgzFy9WmFco=.09b1b596-05ca-4f49-923e-a93aafd8d935@github.com>

On Fri, 13 May 2022 03:12:55 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport 8035134 to fix debuginfo regression, introduced by [JDK-8025936](https://bugs.openjdk.java.net/browse/JDK-8025936).
>> As discussed on [JDK-8281814](https://bugs.openjdk.java.net/browse/JDK-8281814), we cannot see the details of the original patch.
>> It is only a different context, no risk.
>> 
>> Testing: worked correctly after patch.
>
> It looks like it is largely reverted again in [this 11u commit](https://github.com/openjdk/jdk11u-dev/commit//a350f3bda730bc3276e#diff-805224b793cfe47bf6bebf62286f34adb363f0352a9dac3689825b823886e534L882). I'll look at backporting just the changes to that file, as the rest is intrusive or not relevant.
> 
> On Mac, `$1_DEBUGINFO_FILES` contains just a directory, `$$($1_OBJECT_DIR)/$$($1_BASENAME).dSYM` and so ends up empty when this is filtered out. That patch changes the MacOS setup of `$1_DEBUGINFO_FILES` to refer to files.
> 
> It's not clear to me why this `notdir` fix was applied in the first place. The `subst` change in the later commit was identified in [JDK-8281814](https://bugs.openjdk.java.net/browse/JDK-8281814) but not applied.

Hi, @gnu-andrew I have reproduced this problem on a MAC, here is the statements that produced the error:

cd /Users/hedongbo/myprojects/openjdk/jdk8u-dev/build/macosx-x86_64-normal-server-release/jdk/objs/libnpt && /usr/bin/zip -q /Users/hedongbo/myprojects/openjdk/jdk8u-dev/build/macosx-x86_64-normal-server-release/jdk/objs/libnpt/libnpt.diz Info.plist libnpt.dylib && /usr/bin/zip -q /Users/hedongbo/myprojects/openjdk/jdk8u-dev/build/macosx-x86_64-normal-server-release/jdk/objs/libnpt/libnpt.diz Info.plist libnpt.dylib

$ cd /Users/hedongbo/myprojects/openjdk/jdk8u-dev/build/macosx-x86_64-normal-server-release/jdk/objs/libnpt
$ pwd

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/26

From duke at openjdk.java.net  Tue May 17 06:23:57 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Tue, 17 May 2022 06:23:57 GMT
Subject: [jdk8u-dev] RFR: 8130895: Test
 javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
In-Reply-To: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
References: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
Message-ID: <cRZUG0BdLitll61bsvjYE8Tjd0ET_MllpmTXm-UyOcI=.4b0a21fa-e805-4a18-b643-1922fbda48d6@github.com>

On Wed, 11 May 2022 06:37:29 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> I would like to backport
> JDK-8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
> The original patch applies cleanly after paths changes.
> 
> Testing:
> build on Solaris11.4 sparcv9
> tire1, jdk_awt and javax/swing/system/6799345/TestShutdown.java on Solaris11.4 sparcv9

Could someone please review this backport?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/57

From k.takakuri at fujitsu.com  Wed May 18 06:08:54 2022
From: k.takakuri at fujitsu.com (k.takakuri at fujitsu.com)
Date: Wed, 18 May 2022 06:08:54 +0000
Subject: Fix request for jdk8u
Message-ID: <OS0PR01MB577863E2B5E276223ECC7DE988D19@OS0PR01MB5778.jpnprd01.prod.outlook.com>

Hello.
Could someone please check the fix requests for jdk8u?

JDK-8248876
JDK-8278138

I would appreciate your help.

Regards,
K. Takakuri

From sgehwolf at openjdk.java.net  Wed May 18 09:43:06 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 May 2022 09:43:06 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <8aAc8tbabdHcDCg7QSx1WcFsyFoPacZt0fgEZfTg7m0=.e855ec7f-af9c-4c8b-b5db-6d377f3ff803@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
 <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
 <7R5mxoO1jxxf-q9-Ji6b1rKg9cP6zAm5XPRoa94r2Bw=.27a449bd-c532-43e6-80eb-8384562754c3@github.com>
 <8aAc8tbabdHcDCg7QSx1WcFsyFoPacZt0fgEZfTg7m0=.e855ec7f-af9c-4c8b-b5db-6d377f3ff803@github.com>
Message-ID: <nSJA6qBrh5Jw8Wf4eMk-Yn1Cld9t6dzQ9w83kEWO3oI=.20e0ea1a-fb5b-4662-aabe-1430a9a62f59@github.com>

On Tue, 26 Apr 2022 05:19:53 GMT, ktakakuri <duke at openjdk.java.net> wrote:

>> Marked as reviewed by erikj (Reviewer).
>
> @erikj79 
> Would you be willing to be a sponsor?

@ktakakuri The issue this is referencing is resolved. I'm guessing it got resolved with a push to Oracle's JDK 8 fork. The commit for this isn't public so we need to do the SKARA trick to mention the backport bug like so: `Backport JDK-8278138`. I.e. Please change the PR title to `Backport JDK-8278138`. It's strange that skara bots don't flag this with a warning (it's not labelled as a `backport` and the bug is not open anymore).

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From sgehwolf at openjdk.java.net  Wed May 18 09:43:07 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 May 2022 09:43:07 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
 <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
Message-ID: <7Cf7u93lSF7U5En6SMO2s1P8e1auswKgqGvPuxx6YN4=.122ec1bd-9eb7-4316-9420-acee2ac73349@github.com>

On Wed, 13 Apr 2022 08:27:13 GMT, ktakakuri <duke at openjdk.java.net> wrote:

>> Could you please review the 8278138 bug fixes?
>> 
>> This problem is caused by missing DLL's which vcruntime140.dll depends on.
>> I think it is needed to copy the missing DLL's into jdk/bin as like jdk/jre/bin.
>> I fix to copy api-ms-win-*.dll files to jdk/bin when images directory is created.
>
> ktakakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update jdk/make/Images.gmk
>   
>   Co-authored-by: Joakim Nordstr?m <joakim.nordstrom at oracle.com>

Also, please enable PR checks. Perhaps a merge from master would do that.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From sgehwolf at openjdk.java.net  Wed May 18 09:48:06 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 May 2022 09:48:06 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <8aAc8tbabdHcDCg7QSx1WcFsyFoPacZt0fgEZfTg7m0=.e855ec7f-af9c-4c8b-b5db-6d377f3ff803@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
 <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
 <7R5mxoO1jxxf-q9-Ji6b1rKg9cP6zAm5XPRoa94r2Bw=.27a449bd-c532-43e6-80eb-8384562754c3@github.com>
 <8aAc8tbabdHcDCg7QSx1WcFsyFoPacZt0fgEZfTg7m0=.e855ec7f-af9c-4c8b-b5db-6d377f3ff803@github.com>
Message-ID: <2Ymm6pkj87AUqrXybLZTbvNP5w28XxpkAxURH-7TMeY=.afcbcd9e-8046-4f56-be22-b02b5b059cb5@github.com>

On Tue, 26 Apr 2022 05:19:53 GMT, ktakakuri <duke at openjdk.java.net> wrote:

>> Marked as reviewed by erikj (Reviewer).
>
> @erikj79 
> Would you be willing to be a sponsor?

@ktakakuri Once this is being recognized as a backport I'll sponsor it for you.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From sgehwolf at redhat.com  Wed May 18 09:49:00 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 18 May 2022 11:49:00 +0200
Subject: Fix request for jdk8u
In-Reply-To: <OS0PR01MB577863E2B5E276223ECC7DE988D19@OS0PR01MB5778.jpnprd01.prod.outlook.com>
References: <OS0PR01MB577863E2B5E276223ECC7DE988D19@OS0PR01MB5778.jpnprd01.prod.outlook.com>
Message-ID: <53b327f89a8806a1f75356358619bfd18ee38de9.camel@redhat.com>

On Wed, 2022-05-18 at 06:08 +0000, k.takakuri at fujitsu.com wrote:
> Hello.
> Could someone please check the fix requests for jdk8u?
> 
> JDK-8248876
> JDK-8278138
> 
> I would appreciate your help.

Done.

Thanks,
Severin


From duke at openjdk.java.net  Thu May 19 09:54:52 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Thu, 19 May 2022 09:54:52 GMT
Subject: [jdk8u-dev] Integrated: 8278138: OpenJDK8 fails to start on Windows
 8.1 after upgrading compiler to VS2017
In-Reply-To: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
Message-ID: <N7NZFPoPIsvatC2XarsNVCdJG2ezzzyAUhqQ4MvTLN4=.88b367ce-029e-4f91-a702-4cfd87cc8bbe@github.com>

On Tue, 29 Mar 2022 06:43:24 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> Could you please review the 8278138 bug fixes?
> 
> This problem is caused by missing DLL's which vcruntime140.dll depends on.
> I think it is needed to copy the missing DLL's into jdk/bin as like jdk/jre/bin.
> I fix to copy api-ms-win-*.dll files to jdk/bin when images directory is created.

This pull request has now been integrated.

Changeset: 6b94b65d
Author:    ktakakuri <83941312+ktakakuri at users.noreply.github.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/6b94b65db942406c746319957e9c04b92f5507d9
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8278138: OpenJDK8 fails to start on Windows 8.1 after upgrading compiler to VS2017

Reviewed-by: jnordstrom, erikj

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From duke at openjdk.java.net  Thu May 19 11:05:04 2022
From: duke at openjdk.java.net (zzambers)
Date: Thu, 19 May 2022 11:05:04 GMT
Subject: [jdk8u-dev] RFR: 8286989: Build failure on macOS after 8281814
Message-ID: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>

This fixes wrong paths to debuginfo files passed to zip command, causing build failure on MacOS in github workflow. Problem was introduced by JDK-8281814 [1] (integrated, while github workflow PR was still in progress). 

I have done some experiments [2] and found out, that on macos, debuginfo files are stored in additional directories, relative to directory where object files are stored. Removing all directory components is therefore not correct on macos. Two seemingly equivalent fixes were were considered in JDK-8281814 (using notdir and using subst), but chosen one was not the correct one.

Follows example which illustrates difference of different variants of said zip command:

**Prior to JDK-8281814:**
$(ZIP) -q $$@ $$($1_DEBUGINFO_FILES)
- macos:

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

Commit messages:
 - Fixed debuginfo files paths on MacOS

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/61

From dongbohe at openjdk.java.net  Thu May 19 11:05:05 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Thu, 19 May 2022 11:05:05 GMT
Subject: [jdk8u-dev] RFR: 8286989: Build failure on macOS after 8281814
In-Reply-To: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>
References: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>
Message-ID: <zXqk0mfoOVpoo1_GdDqtdnbjTggbd9-eXYtQdomNY_s=.7b060c9e-5893-4384-b851-ef224e66ce88@github.com>

On Wed, 18 May 2022 17:48:08 GMT, zzambers <duke at openjdk.java.net> wrote:

> This fixes wrong paths to debuginfo files passed to zip command, causing build failure on MacOS in github workflow. Problem was introduced by JDK-8281814 [1] (integrated, while github workflow PR was still in progress). 
> 
> I have done some experiments [2] and found out, that on macos, debuginfo files are stored in additional directories, relative to directory where object files are stored. Removing all directory components is therefore not correct on macos. Two seemingly equivalent fixes were were considered in JDK-8281814 (using notdir and using subst), but chosen one was not the correct one.
> 
> Follows example which illustrates difference of different variants of said zip command:
> 
> **Prior to JDK-8281814:**
> $(ZIP) -q $$@ $$($1_DEBUGINFO_FILES)
> - macos:

@zzambers I opened an issue [JDK-8286989](https://bugs.openjdk.java.net/browse/JDK-8286989) on JBS, you can use it in your PR(ie, change the PR title to `8286989: Build failure on macOS after 8281814`), then the bot can recognize this PR.

This change looks fine to me.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/61

From duke at openjdk.java.net  Thu May 19 11:05:07 2022
From: duke at openjdk.java.net (zzambers)
Date: Thu, 19 May 2022 11:05:07 GMT
Subject: [jdk8u-dev] RFR: 8286989: Build failure on macOS after 8281814
In-Reply-To: <zXqk0mfoOVpoo1_GdDqtdnbjTggbd9-eXYtQdomNY_s=.7b060c9e-5893-4384-b851-ef224e66ce88@github.com>
References: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>
 <zXqk0mfoOVpoo1_GdDqtdnbjTggbd9-eXYtQdomNY_s=.7b060c9e-5893-4384-b851-ef224e66ce88@github.com>
Message-ID: <0j1S4247IQh4EO94iqUaUt5TyQOJbvkBvaVpXICAF6M=.88cf3105-1ca3-4767-96d3-0f5bde926781@github.com>

On Thu, 19 May 2022 03:54:41 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> This fixes wrong paths to debuginfo files passed to zip command, causing build failure on MacOS in github workflow. Problem was introduced by JDK-8281814 [1] (integrated, while github workflow PR was still in progress). 
>> 
>> I have done some experiments [2] and found out, that on macos, debuginfo files are stored in additional directories, relative to directory where object files are stored. Removing all directory components is therefore not correct on macos. Two seemingly equivalent fixes were were considered in JDK-8281814 (using notdir and using subst), but chosen one was not the correct one.
>> 
>> Follows example which illustrates difference of different variants of said zip command:
>> 
>> **Prior to JDK-8281814:**
>> $(ZIP) -q $$@ $$($1_DEBUGINFO_FILES)
>> - macos:
>
> This change looks fine to me.

@dongbohe Thank you

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/61

From duke at openjdk.java.net  Thu May 19 12:34:31 2022
From: duke at openjdk.java.net (zzambers)
Date: Thu, 19 May 2022 12:34:31 GMT
Subject: [jdk8u-dev] RFR: 8286989: Build failure on macOS after 8281814
 [v2]
In-Reply-To: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>
References: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>
Message-ID: <lzyWO7f2gIA8m0OkcBY5MBWkNdT2RveA6P7t7-6hi_k=.a695d537-04d5-4179-a1c2-1cdcff5ea735@github.com>

> This fixes wrong paths to debuginfo files passed to zip command, causing build failure on MacOS in github workflow. Problem was introduced by JDK-8281814 [1] (integrated, while github workflow PR was still in progress). 
> 
> I have done some experiments [2] and found out, that on macos, debuginfo files are stored in additional directories, relative to directory where object files are stored. Removing all directory components is therefore not correct on macos. Two seemingly equivalent fixes were were considered in JDK-8281814 (using notdir and using subst), but chosen one was not the correct one.
> 
> Follows example which illustrates difference of different variants of said zip command:
> 
> **Prior to JDK-8281814:**
> $(ZIP) -q $$@ $$($1_DEBUGINFO_FILES)
> - macos:

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

  Removed unnecessary space

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/61/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/61/files/ad6bbf93..a5907059

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/61.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/61/head:pull/61

PR: https://git.openjdk.java.net/jdk8u-dev/pull/61

From omikhaltcova at openjdk.java.net  Thu May 19 15:25:28 2022
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Thu, 19 May 2022 15:25:28 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components
Message-ID: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>

I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
The original patch applied not cleanly due to 2 files:
   

>  MotifLookAndFeel.java - differences in the header and in the context;
>  SwingUtilities2.java - difference in the context.

Tested on Windows. All regular tests passed.

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

Commit messages:
 - Backport 91f281c8d713e489ddc282f935ebd879485c4b41

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/60/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=60&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8194873
  Stats: 371 lines in 11 files changed: 359 ins; 6 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/60.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/60/head:pull/60

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From duke at openjdk.java.net  Thu May 19 15:27:44 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Thu, 19 May 2022 15:27:44 GMT
Subject: [jdk8u-dev] Integrated: 8248876: LoadObject with bad base address
 created for exec file on linux
In-Reply-To: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
References: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
Message-ID: <Kj2DVTiiZJWxQHXC3zgp4KVS7H9O1nS-fwKSiuk7FDY=.9b9a5cd5-8151-4f49-b13c-28e61085e533@github.com>

On Mon, 25 Apr 2022 08:08:21 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> I would like to backport
> 8248876: LoadObject with bad base address created for exec file on linux.
> 
> The original patch does not apply cleanly to 8u, and this is a clean backport from 11u.
> 
> Testing:
> build on Linux x86_64
> tier1 on Linux x86_64

This pull request has now been integrated.

Changeset: 3e0eb096
Author:    Takakuri <k.takakuri at fujitsu.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/3e0eb096153e9b7f4c2ed367c9282d09307bbd6b
Stats:     18 lines in 2 files changed: 4 ins; 3 del; 11 mod

8248876: LoadObject with bad base address created for exec file on linux

Reviewed-by: phh
Backport-of: 9d59dec200490f11bfc1c661b30f10c7edee3a6d

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/47

From andrew at openjdk.java.net  Mon May 23 00:14:45 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 23 May 2022 00:14:45 GMT
Subject: [jdk8u-dev] RFR: 8248876: LoadObject with bad base address created
 for exec file on linux
In-Reply-To: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
References: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
Message-ID: <MKpMSj7hUUfrhA-tlmZaVB1OyyEDuH8JOWkP55DByhY=.6ff9e59e-22fa-4b79-b315-8e118b7e5f07@github.com>

On Mon, 25 Apr 2022 08:08:21 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> I would like to backport
> 8248876: LoadObject with bad base address created for exec file on linux.
> 
> The original patch does not apply cleanly to 8u, and this is a clean backport from 11u.
> 
> Testing:
> build on Linux x86_64
> tier1 on Linux x86_64

> /sponsor
> 
> Got the approval. Presubmit failures appear to be an infrastructure problem.

This has been fixed by JDK-8284772 for some time. For future such PRs, I'd suggest a rebase so the tests are re-run.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/47

From andrew at openjdk.java.net  Mon May 23 00:31:35 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 23 May 2022 00:31:35 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information
Message-ID: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>

In implementing [JDK-8222975](https://bugs.openjdk.java.net/browse/JDK-8222975) and backporting [JDK-8210283](https://bugs.openjdk.java.net/browse/JDK-8210283), we have avoided backporting [JDK-8031567](https://bugs.openjdk.java.net/browse/JDK-8031567) in order to keep things simple. However, the net result has been that we have introduced [unique 8u bugs](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-April/014842.html)

Rather than just patching up 8u again, it seems to make sense to just bring it into line with later JDKs. There might have been a reason to keep 8u different when it was a forest of Mercurial repositories, but it is now a single Git tree like the other JDK repositories. Handling the same thing but in a unique way just makes any future backporting harder to deal with.

In light of this, I've now backported 8031567. I started by reverting the two 8u-specific patches, 8210283 & 8222975, and then applied 8136771 & 8031567 (which includes 8222975), along with follow-up fixes 8170385 & 8170392. 8210283 was then rebackported on top of this.

A couple of additional fixes were then made to workaround Makefile differences in 8u. Due to the lack of [JDK-8069261](https://bugs.openjdk.java.net/browse/JDK-8069261) the `MakeDir` usage needs to be wrapped in `eval`. 8u also doesn't have the modern macro format from  [JDK-8074988](https://bugs.openjdk.java.net/browse/JDK-8074988) and earlier fixes, so the `SetupGetRevisionForRepo` macro was modified to work in a similar way to other macros do in 8u. The stripping of `$1` is necessary to avoid it trying to create variables beginning with a space (something which led to empty variables and confused me for some time)

I did consider backporting those as well, but felt there were too intrusive to other areas of the build. At least we now have a template in this patch for how to convert any future instances.

The end result actually looks pretty straightforward and differences between this and the `make/SourceRevision.gmk` file in 11u are small.

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

Commit messages:
 - Fix SetupGetRevisionForRepo to workaround lack of JDK-8074988
 - Use eval wrapper for MakeDir calls due to lack of JDK-8069261
 - 8210283: Support git as an SCM alternative in the build
 - 8170392: JDK-8031567 broke builds from source bundles
 - 8170385: JDK-8031567 broke source bundles
 - 8031567: Better model for storing source revision information
 - 8136771: Implement the license-swap logic as a make target
 - Revert "8222975: Fix 'release' file to reflect actual repo checkin used to compile JDK"
 - Revert "8210283: Support git as an SCM alternative in the build"

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/62/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=62&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8031567
  Stats: 267 lines in 13 files changed: 190 ins; 45 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/62/head:pull/62

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From andrew at openjdk.java.net  Mon May 23 00:40:38 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 23 May 2022 00:40:38 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information [v2]
In-Reply-To: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
Message-ID: <oL9Gxd7o-0F0wkQPq9PNE-ebZkPFk5w2H3m37-pSNDM=.08a3c818-5486-42d7-ae58-8accb0f179a5@github.com>

> In implementing [JDK-8222975](https://bugs.openjdk.java.net/browse/JDK-8222975) and backporting [JDK-8210283](https://bugs.openjdk.java.net/browse/JDK-8210283), we have avoided backporting [JDK-8031567](https://bugs.openjdk.java.net/browse/JDK-8031567) in order to keep things simple. However, the net result has been that we have introduced [unique 8u bugs](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-April/014842.html)
> 
> Rather than just patching up 8u again, it seems to make sense to just bring it into line with later JDKs. There might have been a reason to keep 8u different when it was a forest of Mercurial repositories, but it is now a single Git tree like the other JDK repositories. Handling the same thing but in a unique way just makes any future backporting harder to deal with.
> 
> In light of this, I've now backported 8031567. I started by reverting the two 8u-specific patches, 8210283 & 8222975, and then applied 8136771 & 8031567 (which includes 8222975), along with follow-up fixes 8170385 & 8170392. 8210283 was then rebackported on top of this.
> 
> A couple of additional fixes were then made to workaround Makefile differences in 8u. Due to the lack of [JDK-8069261](https://bugs.openjdk.java.net/browse/JDK-8069261) the `MakeDir` usage needs to be wrapped in `eval`. 8u also doesn't have the modern macro format from  [JDK-8074988](https://bugs.openjdk.java.net/browse/JDK-8074988) and earlier fixes, so the `SetupGetRevisionForRepo` macro was modified to work in a similar way to other macros do in 8u. The stripping of `$1` is necessary to avoid it trying to create variables beginning with a space (something which led to empty variables and confused me for some time)
> 
> I did consider backporting those as well, but felt there were too intrusive to other areas of the build. At least we now have a template in this patch for how to convert any future instances.
> 
> The end result actually looks pretty straightforward and differences between this and the `make/SourceRevision.gmk` file in 11u are small.

Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:

  Remove stray brackets

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/62/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/62/files/1b2bc219..3f4af272

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/62/head:pull/62

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From andrew at openjdk.java.net  Mon May 23 00:42:20 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 23 May 2022 00:42:20 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information
In-Reply-To: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
Message-ID: <BBtky8qsF-lYA_5FyXWPGwcLoQvMohTDPLNDnzJvUvQ=.ef8f9d62-5098-4833-b846-f4f50c4fe521@github.com>

On Mon, 23 May 2022 00:24:22 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> In implementing [JDK-8222975](https://bugs.openjdk.java.net/browse/JDK-8222975) and backporting [JDK-8210283](https://bugs.openjdk.java.net/browse/JDK-8210283), we have avoided backporting [JDK-8031567](https://bugs.openjdk.java.net/browse/JDK-8031567) in order to keep things simple. However, the net result has been that we have introduced [unique 8u bugs](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-April/014842.html)
> 
> Rather than just patching up 8u again, it seems to make sense to just bring it into line with later JDKs. There might have been a reason to keep 8u different when it was a forest of Mercurial repositories, but it is now a single Git tree like the other JDK repositories. Handling the same thing but in a unique way just makes any future backporting harder to deal with.
> 
> In light of this, I've now backported 8031567. I started by reverting the two 8u-specific patches, 8210283 & 8222975, and then applied 8136771 & 8031567 (which includes 8222975), along with follow-up fixes 8170385 & 8170392. 8210283 was then rebackported on top of this.
> 
> A couple of additional fixes were then made to workaround Makefile differences in 8u. Due to the lack of [JDK-8069261](https://bugs.openjdk.java.net/browse/JDK-8069261) the `MakeDir` usage needs to be wrapped in `eval`. 8u also doesn't have the modern macro format from  [JDK-8074988](https://bugs.openjdk.java.net/browse/JDK-8074988) and earlier fixes, so the `SetupGetRevisionForRepo` macro was modified to work in a similar way to other macros do in 8u. The stripping of `$1` is necessary to avoid it trying to create variables beginning with a space (something which led to empty variables and confused me for some time)
> 
> I did consider backporting those as well, but felt there were too intrusive to other areas of the build. At least we now have a template in this patch for how to convert any future instances.
> 
> The end result actually looks pretty straightforward and differences between this and the `make/SourceRevision.gmk` file in 11u are small.

Looks like 8136771 is private.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From andrew at openjdk.java.net  Mon May 23 00:52:03 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 23 May 2022 00:52:03 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information [v2]
In-Reply-To: <oL9Gxd7o-0F0wkQPq9PNE-ebZkPFk5w2H3m37-pSNDM=.08a3c818-5486-42d7-ae58-8accb0f179a5@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
 <oL9Gxd7o-0F0wkQPq9PNE-ebZkPFk5w2H3m37-pSNDM=.08a3c818-5486-42d7-ae58-8accb0f179a5@github.com>
Message-ID: <k9jvG9QuiQzr4yLfidc2QgrmbRhukGcp7c2y-YDghD0=.1b0747e7-3b16-4274-b0e2-0924cac2b9ba@github.com>

On Mon, 23 May 2022 00:40:38 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> In implementing [JDK-8222975](https://bugs.openjdk.java.net/browse/JDK-8222975) and backporting [JDK-8210283](https://bugs.openjdk.java.net/browse/JDK-8210283), we have avoided backporting [JDK-8031567](https://bugs.openjdk.java.net/browse/JDK-8031567) in order to keep things simple. However, the net result has been that we have introduced [unique 8u bugs](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-April/014842.html)
>> 
>> Rather than just patching up 8u again, it seems to make sense to just bring it into line with later JDKs. There might have been a reason to keep 8u different when it was a forest of Mercurial repositories, but it is now a single Git tree like the other JDK repositories. Handling the same thing but in a unique way just makes any future backporting harder to deal with.
>> 
>> In light of this, I've now backported 8031567. I started by reverting the two 8u-specific patches, 8210283 & 8222975, and then applied 8136771 & 8031567 (which includes 8222975), along with follow-up fixes 8170385 & 8170392. 8210283 was then rebackported on top of this.
>> 
>> A couple of additional fixes were then made to workaround Makefile differences in 8u. Due to the lack of [JDK-8069261](https://bugs.openjdk.java.net/browse/JDK-8069261) the `MakeDir` usage needs to be wrapped in `eval`. 8u also doesn't have the modern macro format from  [JDK-8074988](https://bugs.openjdk.java.net/browse/JDK-8074988) and earlier fixes, so the `SetupGetRevisionForRepo` macro was modified to work in a similar way to other macros do in 8u. The stripping of `$1` is necessary to avoid it trying to create variables beginning with a space (something which led to empty variables and confused me for some time)
>> 
>> I did consider backporting those as well, but felt there were too intrusive to other areas of the build. At least we now have a template in this patch for how to convert any future instances.
>> 
>> The end result actually looks pretty straightforward and differences between this and the `make/SourceRevision.gmk` file in 11u are small.
>
> Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stray brackets

Note that this PR also updates `common/autoconf/generated-configure.sh` which was missed by #33

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From andrew at openjdk.java.net  Mon May 23 03:57:54 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 23 May 2022 03:57:54 GMT
Subject: [jdk8u-dev] RFR: 8285523: Improve test
 java/io/FileOutputStream/OpenNUL.java
In-Reply-To: <QU81rxZ40IsPmjhtSsPnClLVpCIKD9wQApFHp8zD7Go=.778efb23-a001-4433-9bec-cbf0a78288a6@github.com>
References: <QU81rxZ40IsPmjhtSsPnClLVpCIKD9wQApFHp8zD7Go=.778efb23-a001-4433-9bec-cbf0a78288a6@github.com>
Message-ID: <tG1iGbQZqsENVwlhYLMprKy3sORGUzRmAbWTC7epeqo=.041f13bd-45bd-49f0-a1a5-f349dc65e2d7@github.com>

On Mon, 16 May 2022 01:28:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [f42631e3](https://github.com/openjdk/jdk/commit/f42631e354d4abf7994abd92aa5def6b2ceeab3a) from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository.
> The commit being backported was authored by Sergey Bylokhov on 29 Apr 2022 and was reviewed by Andrew John Hughes and Brian Burkhalter.
> Thanks!

Approved for 8u

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/59

From duke at openjdk.java.net  Mon May 23 05:50:59 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Mon, 23 May 2022 05:50:59 GMT
Subject: [jdk8u-dev] RFR: 8197859: VS2017 Complains about UINTPTR_MAX
 definition in globalDefinitions_VisCPP.hpp
In-Reply-To: <MGeIIf-W3hQOM7mbOpSh5zsO2NRca8WgMq7dH4c44V4=.cc25e5ed-7091-475f-8c63-4d9527095c5b@github.com>
References: <MGeIIf-W3hQOM7mbOpSh5zsO2NRca8WgMq7dH4c44V4=.cc25e5ed-7091-475f-8c63-4d9527095c5b@github.com>
Message-ID: <_ahN4ylggb8R64-kOI4bIS_zYB7tUsZhN6aM8hcud-A=.ce768b07-9ad8-4415-8c1f-9b874f507084@github.com>

On Fri, 13 May 2022 08:31:52 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

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

ping

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/58

From duke at openjdk.java.net  Mon May 23 06:07:48 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Mon, 23 May 2022 06:07:48 GMT
Subject: [jdk8u-dev] RFR: 8130895: Test
 javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
In-Reply-To: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
References: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
Message-ID: <KeJKLEYxlz5Ogse5XxDmYSK7eKimN7UzU2UepO20ftY=.548c9754-4ad2-4e60-b10c-cc689bcc566d@github.com>

On Wed, 11 May 2022 06:37:29 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> I would like to backport
> JDK-8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
> The original patch applies cleanly after paths changes.
> 
> Testing:
> build on Solaris11.4 sparcv9
> tire1, jdk_awt and javax/swing/system/6799345/TestShutdown.java on Solaris11.4 sparcv9

Could anyone review the PR please?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/57

From dcherepanov at openjdk.java.net  Mon May 23 09:45:24 2022
From: dcherepanov at openjdk.java.net (Dmitry Cherepanov)
Date: Mon, 23 May 2022 09:45:24 GMT
Subject: [jdk8u-dev] RFR: 8283350: (tz) Update Timezone Data to 2022a
Message-ID: <yCrjNHxq7-36uij01Ywi8jdYHoVLvflACLULiDBK8Zg=.2869debe-6b9a-4897-8296-436ee47d591f@github.com>

Please review the update to tzdata2022a

 - updated manually from the rearguard version (tzdata2022a-rearguard.tar.gz generated by `cd tzdb-2022a && make rearguard_tarballs`)
 - updated the copy of the timezone data in the test folder

Testing: tests for sun.util.calendar and java.time.test passed

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

Commit messages:
 - 8283350: (tz) Update Timezone Data to 2022a

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/63/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=63&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283350
  Stats: 214 lines in 12 files changed: 156 ins; 0 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/63.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/63/head:pull/63

PR: https://git.openjdk.java.net/jdk8u-dev/pull/63

From yan at openjdk.java.net  Mon May 23 14:38:37 2022
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Mon, 23 May 2022 14:38:37 GMT
Subject: [jdk8u-dev] RFR: 8285727: [11u,
 17u] Unify fix for JDK-8284920 with version from head
Message-ID: <jeYS3grzvjV4F-0bWc_HYt3DRB4SDXvM4aUqvfZs1FI=.5fc45135-9613-428d-8015-f5ea788a203a@github.com>

I need to backport this fix prepared by Christoph Langer to jdk8u, too. Without it, further backports using Token would be painful. The fix is not technically a backport from upstream for obvious reason so it would require review etc.

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

Commit messages:
 - 8285727: [11u, 17u] Unify fix for JDK-8284920 with version

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/64

From sgehwolf at openjdk.java.net  Mon May 23 16:58:57 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 23 May 2022 16:58:57 GMT
Subject: [jdk8u-dev] RFR: 8285727: [11u,
 17u] Unify fix for JDK-8284920 with version from head
In-Reply-To: <jeYS3grzvjV4F-0bWc_HYt3DRB4SDXvM4aUqvfZs1FI=.5fc45135-9613-428d-8015-f5ea788a203a@github.com>
References: <jeYS3grzvjV4F-0bWc_HYt3DRB4SDXvM4aUqvfZs1FI=.5fc45135-9613-428d-8015-f5ea788a203a@github.com>
Message-ID: <xetZs6CQvpcF_uQA33srCAcJzfK7TTJ8bPKKlbCSfAI=.ff320671-ab76-40e0-9675-582deb2a8dd9@github.com>

On Mon, 23 May 2022 14:30:34 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> I need to backport this fix prepared by Christoph Langer to jdk8u, too. Without it, further backports using Token would be painful. The fix is not technically a backport from upstream for obvious reason so it would require review etc.

@yan-too Could you please change the PR title to `Backport a95482acf83cc03bc562baace0d55d831d0b2b41` as it's really a backport of that change in JDK 17 (modulo path changes). Right now the bot complains about the issue not being open.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/64

From duke at openjdk.java.net  Tue May 24 01:49:09 2022
From: duke at openjdk.java.net (wxiang)
Date: Tue, 24 May 2022 01:49:09 GMT
Subject: [jdk8u-dev] RFR: 8287191: [8u] Build failure without git information
Message-ID: <u2wL5M_3SIiF313SxhtuA2PABg6pfawV08-NU7zD-lw=.c808d94e-ec5a-4a12-93c3-6d28bbc49b00@github.com>

In 8u332, the commit "8210283: Support git as an SCM alternative in the build? used git as an SCM.
In the source package ?https://github.com/openjdk/jdk8u/archive/refs/tags/jdk8u332-ga.tar.gz?? 
the .git directory has been removed in the source package. 

When we compile JDK with the source code from the package, we get the below error: 
``` 
Building 'linux-x86_64-normal-server-release' (matching CONF=release)

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

Commit messages:
 - 8287191: [8u] Build failure without git information

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/65

From dholmes at openjdk.java.net  Tue May 24 02:50:23 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 24 May 2022 02:50:23 GMT
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so that it
 always throws UOE
Message-ID: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>

Please review these further changes for JDK 8 Maintenance Release 4 - JSR-337.

The MR4 changes to the reference processing implementation have made continued support for `runFinalizersonExit` unreasonable and so it is "retired" and will always throw `UnsupportedOperationException`. (This is what was also done for `Thread.stop(Throwable)` in JDK 8.)

Various updates to the specifications are made to remove references to running finalizers at exit - see the CSR request for details.

All dead code (including the already dead `JVM_Exit`) is removed. Shutdown.java is replaced by the version from mainline with a slight modification as 8u doesn't have `sun.misc.VM.isShutdown()`.

Tests using RFOE are deleted and a new test to check the throwing of UOE added. The new test was NOT a rename of an existing test but for some reason git is treating it that way.

Testing: :jdk_core group

Thanks,
David

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

Commit messages:
 - Fix test
 - add missing bug id
 - 8287132: Retire Runtime.runFinalizersOnExit so that it always throws UOE

Changes: https://git.openjdk.java.net/jdk8u-ri/pull/9/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=9&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287132
  Stats: 573 lines in 25 files changed: 98 ins; 364 del; 111 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/9/head:pull/9

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From serb at openjdk.java.net  Tue May 24 05:52:00 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 24 May 2022 05:52:00 GMT
Subject: [jdk8u-dev] Integrated: 8285523: Improve test
 java/io/FileOutputStream/OpenNUL.java
In-Reply-To: <QU81rxZ40IsPmjhtSsPnClLVpCIKD9wQApFHp8zD7Go=.778efb23-a001-4433-9bec-cbf0a78288a6@github.com>
References: <QU81rxZ40IsPmjhtSsPnClLVpCIKD9wQApFHp8zD7Go=.778efb23-a001-4433-9bec-cbf0a78288a6@github.com>
Message-ID: <kYgzND95xdbi86555v5W3Nxg1pWGxXK_g44rPiOihjA=.34b524a8-436f-4dde-add6-1f9121243ad3@github.com>

On Mon, 16 May 2022 01:28:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [f42631e3](https://github.com/openjdk/jdk/commit/f42631e354d4abf7994abd92aa5def6b2ceeab3a) from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository.
> The commit being backported was authored by Sergey Bylokhov on 29 Apr 2022 and was reviewed by Andrew John Hughes and Brian Burkhalter.
> Thanks!

This pull request has now been integrated.

Changeset: db52470b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/db52470b5fdcf48490bef30891424d23fe6b57dc
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8285523: Improve test java/io/FileOutputStream/OpenNUL.java

Reviewed-by: andrew
Backport-of: f42631e354d4abf7994abd92aa5def6b2ceeab3a

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/59

From yan at openjdk.java.net  Tue May 24 06:34:50 2022
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Tue, 24 May 2022 06:34:50 GMT
Subject: [jdk8u-dev] RFR: 8285727: [11u,
 17u] Unify fix for JDK-8284920 with version from head
In-Reply-To: <xetZs6CQvpcF_uQA33srCAcJzfK7TTJ8bPKKlbCSfAI=.ff320671-ab76-40e0-9675-582deb2a8dd9@github.com>
References: <jeYS3grzvjV4F-0bWc_HYt3DRB4SDXvM4aUqvfZs1FI=.5fc45135-9613-428d-8015-f5ea788a203a@github.com>
 <xetZs6CQvpcF_uQA33srCAcJzfK7TTJ8bPKKlbCSfAI=.ff320671-ab76-40e0-9675-582deb2a8dd9@github.com>
Message-ID: <9wj2WfT7OaRjpZHPjLqxUwK19ZVIuvMCVU7e34L--vo=.973de98b-932d-43de-912b-1669d50739f5@github.com>

On Mon, 23 May 2022 16:55:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I need to backport this fix prepared by Christoph Langer to jdk8u, too. Without it, further backports using Token would be painful. The fix is not technically a backport from upstream for obvious reason so it would require review etc.
>
> @yan-too Could you please change the PR title to `Backport a95482acf83cc03bc562baace0d55d831d0b2b41` as it's really a backport of that change in JDK 17 (modulo path changes). Right now the bot complains about the issue not being open.

@jerboaa Actually that complain is quite common thing because  8285727 indeed is not open: it is Resolved/Fixed. I will change the title but I'm afraid there might be a problem in future since a95482acf83cc03bc562baace0d55d831d0b2b41 _is not in head_ as would be usual for the regular fixes (not backports) in 17. History of it stops in 17. Let's see though...

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/64

From sgehwolf at openjdk.java.net  Tue May 24 08:48:01 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 08:48:01 GMT
Subject: [jdk8u-dev] RFR: 8285727: [11u,
 17u] Unify fix for JDK-8284920 with version from head
In-Reply-To: <xetZs6CQvpcF_uQA33srCAcJzfK7TTJ8bPKKlbCSfAI=.ff320671-ab76-40e0-9675-582deb2a8dd9@github.com>
References: <jeYS3grzvjV4F-0bWc_HYt3DRB4SDXvM4aUqvfZs1FI=.5fc45135-9613-428d-8015-f5ea788a203a@github.com>
 <xetZs6CQvpcF_uQA33srCAcJzfK7TTJ8bPKKlbCSfAI=.ff320671-ab76-40e0-9675-582deb2a8dd9@github.com>
Message-ID: <NXoR3cyud0eP-rOZqKdYjZZb6w-2FzbYUM6eFJ3pZeU=.7f637fd7-e27d-4abc-9d3a-640efb803d75@github.com>

On Mon, 23 May 2022 16:55:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I need to backport this fix prepared by Christoph Langer to jdk8u, too. Without it, further backports using Token would be painful. The fix is not technically a backport from upstream for obvious reason so it would require review etc.
>
> @yan-too Could you please change the PR title to `Backport a95482acf83cc03bc562baace0d55d831d0b2b41` as it's really a backport of that change in JDK 17 (modulo path changes). Right now the bot complains about the issue not being open.

> @jerboaa Actually that complain is quite common thing because 8285727 indeed is not open: it is Resolved/Fixed. I will change the title but I'm afraid there might be a problem in future since a95482acf83cc03bc562baace0d55d831d0b2b41 _is not in head_ as would be usual for the regular fixes (not backports) in 17. History of it stops in 17. Let's see though... it works! openjdk bot says "...with version from head" but has found the hash in 17u. Openjdk looks like hydra :-)

Thanks! Yeah, the original change was in 17 and downward, but it's still a backport of the JDK 17 unification change. jdk head got the same change with JDK-8284920.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/64

From sgehwolf at openjdk.java.net  Tue May 24 12:11:02 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 12:11:02 GMT
Subject: [jdk8u-dev] RFR: 8285727: [11u,
 17u] Unify fix for JDK-8284920 with version from head
In-Reply-To: <jeYS3grzvjV4F-0bWc_HYt3DRB4SDXvM4aUqvfZs1FI=.5fc45135-9613-428d-8015-f5ea788a203a@github.com>
References: <jeYS3grzvjV4F-0bWc_HYt3DRB4SDXvM4aUqvfZs1FI=.5fc45135-9613-428d-8015-f5ea788a203a@github.com>
Message-ID: <k0jGHuAu4E1zVi1EPyxi5XQOSw72U4Em-bEkcRab4T8=.0301d033-fdc3-4c7d-8336-096383708ef8@github.com>

On Mon, 23 May 2022 14:30:34 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> I need to backport this fix prepared by Christoph Langer to jdk8u, too. Without it, further backports using Token would be painful. The fix is not technically a backport from upstream for obvious reason so it would require review etc.

This is a clean backport modulo path changes. Trying to mark as such.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/64

From yan at openjdk.java.net  Tue May 24 12:24:57 2022
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Tue, 24 May 2022 12:24:57 GMT
Subject: [jdk8u-dev] RFR: 8285727: [11u,
 17u] Unify fix for JDK-8284920 with version from head
In-Reply-To: <k0jGHuAu4E1zVi1EPyxi5XQOSw72U4Em-bEkcRab4T8=.0301d033-fdc3-4c7d-8336-096383708ef8@github.com>
References: <jeYS3grzvjV4F-0bWc_HYt3DRB4SDXvM4aUqvfZs1FI=.5fc45135-9613-428d-8015-f5ea788a203a@github.com>
 <k0jGHuAu4E1zVi1EPyxi5XQOSw72U4Em-bEkcRab4T8=.0301d033-fdc3-4c7d-8336-096383708ef8@github.com>
Message-ID: <E8YBUU2ZUtPpqTll8C5nCTGNO3YYfruR7aH95xRusAI=.e22af7da-5237-4f6a-a003-ca88680f1730@github.com>

On Tue, 24 May 2022 12:07:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I need to backport this fix prepared by Christoph Langer to jdk8u, too. Without it, further backports using Token would be painful. The fix is not technically a backport from upstream for obvious reason so it would require review etc.
>
> This is a clean backport modulo path changes. Trying to mark as such.

Thank you, @jerboaa! This trick with forced clean also works (I tried it several times before with different results).

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/64

From dholmes at openjdk.java.net  Tue May 24 12:41:55 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 24 May 2022 12:41:55 GMT
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE [v2]
In-Reply-To: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
References: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
Message-ID: <2A8v2uy4-f4H1Yi1wdhALGjBAmiSs1gZSmW6OezV1Sg=.a2c15412-1379-4a18-9b83-e1decc4c703b@github.com>

> Please review these further changes for JDK 8 Maintenance Release 4 - JSR-337.
> 
> The MR4 changes to the reference processing implementation have made continued support for `runFinalizersonExit` unreasonable and so it is "retired" and will always throw `UnsupportedOperationException`. (This is what was also done for `Thread.stop(Throwable)` in JDK 8.)
> 
> Various updates to the specifications are made to remove references to running finalizers at exit - see the CSR request for details.
> 
> All dead code (including the already dead `JVM_Exit`) is removed. Shutdown.java is replaced by the version from mainline with a slight modification as 8u doesn't have `sun.misc.VM.isShutdown()`.
> 
> Tests using RFOE are deleted and a new test to check the throwing of UOE added. The new test was NOT a rename of an existing test but for some reason git is treating it that way.
> 
> Testing: :jdk_core group
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Missing paragraph tag.

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-ri/pull/9/files
  - new: https://git.openjdk.java.net/jdk8u-ri/pull/9/files/a3dbf528..3de362a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=9&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=9&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/9/head:pull/9

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From sgehwolf at openjdk.java.net  Tue May 24 12:45:01 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 12:45:01 GMT
Subject: [jdk8u-dev] RFR: 8287191: [8u] Build failure without git
 information
In-Reply-To: <u2wL5M_3SIiF313SxhtuA2PABg6pfawV08-NU7zD-lw=.c808d94e-ec5a-4a12-93c3-6d28bbc49b00@github.com>
References: <u2wL5M_3SIiF313SxhtuA2PABg6pfawV08-NU7zD-lw=.c808d94e-ec5a-4a12-93c3-6d28bbc49b00@github.com>
Message-ID: <Po5zkSTHkq4DAo3jkogTT7sCNmIyX4PybgCiaRdv79Y=.fb29bb37-fd3c-42a6-9ae7-bf447d349128@github.com>

On Tue, 24 May 2022 01:44:05 GMT, wxiang <duke at openjdk.java.net> wrote:

> In 8u332, the commit "8210283: Support git as an SCM alternative in the build? used git as an SCM.
> In the source package ?https://github.com/openjdk/jdk8u/archive/refs/tags/jdk8u332-ga.tar.gz?? 
> the .git directory has been removed in the source package. 
> 
> When we compile JDK with the source code from the package, we get the below error: 
> ``` 
> Building 'linux-x86_64-normal-server-release' (matching CONF=release)

Please see #62 which should fix this.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/65

From zgu at openjdk.java.net  Tue May 24 12:54:08 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 24 May 2022 12:54:08 GMT
Subject: [jdk8u-dev] Integrated: 8284620: CodeBuffer may leak _overflow_arena
In-Reply-To: <0_0B3Wbda4gVbRm3uG08U7LME-LsSx6BR8UCLcc_1R0=.aaa95d24-1947-409d-84a0-2361d507ef7d@github.com>
References: <0_0B3Wbda4gVbRm3uG08U7LME-LsSx6BR8UCLcc_1R0=.aaa95d24-1947-409d-84a0-2361d507ef7d@github.com>
Message-ID: <VHcNlGvZf56I3AYBfkc1Sy-LP1oli_BGsOzO9Nih0jM=.205d0e25-d3c2-4043-8bd1-41d2bae5c286@github.com>

On Mon, 2 May 2022 12:32:21 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to backport this patch to 8u for fixing a memory leak.
> 
> The original patch does not apply cleanly due to context difference. However, the patch is small, easily resolved manually.
> 
> Test:
> 
> - [x]  hotspot_compiler

This pull request has now been integrated.

Changeset: eb5711be
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/eb5711bebec7bc655629b9471d6a52bdec76c5c2
Stats:     5 lines in 1 file changed: 3 ins; 2 del; 0 mod

8284620: CodeBuffer may leak _overflow_arena

Reviewed-by: phh
Backport-of: 4d45c3ebc493bb2c85dab84b97840c8ba093ab1f

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/52

From sgehwolf at openjdk.java.net  Tue May 24 12:59:01 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 12:59:01 GMT
Subject: [jdk8u-dev] RFR: 8283350: (tz) Update Timezone Data to 2022a
In-Reply-To: <yCrjNHxq7-36uij01Ywi8jdYHoVLvflACLULiDBK8Zg=.2869debe-6b9a-4897-8296-436ee47d591f@github.com>
References: <yCrjNHxq7-36uij01Ywi8jdYHoVLvflACLULiDBK8Zg=.2869debe-6b9a-4897-8296-436ee47d591f@github.com>
Message-ID: <cRrv8SEwbWxHcO7D_ZiyYP69ilyJahxpPG1DM0GrrP4=.4a090b5c-db86-4313-a2be-162836eb6ed6@github.com>

On Mon, 23 May 2022 09:38:06 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Please review the update to tzdata2022a
> 
>  - updated manually from the rearguard version (tzdata2022a-rearguard.tar.gz generated by `cd tzdb-2022a && make rearguard_tarballs`)
>  - updated the copy of the timezone data in the test folder
> 
> Testing: tests for sun.util.calendar and java.time.test passed

@dimitryc Please change the PR title to `Backport b05d4ccf8e54635c16bc2c26aa7a8fcc2e3b3dde` as it's a backport of that update (I see the issue is not open warning).

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/63

From sgehwolf at openjdk.java.net  Tue May 24 13:01:58 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 13:01:58 GMT
Subject: [jdk8u-dev] RFR: 8286989: Build failure on macOS after 8281814
 [v2]
In-Reply-To: <lzyWO7f2gIA8m0OkcBY5MBWkNdT2RveA6P7t7-6hi_k=.a695d537-04d5-4179-a1c2-1cdcff5ea735@github.com>
References: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>
 <lzyWO7f2gIA8m0OkcBY5MBWkNdT2RveA6P7t7-6hi_k=.a695d537-04d5-4179-a1c2-1cdcff5ea735@github.com>
Message-ID: <L3tbZU2tMYOLnmQmQowALakowPvcfpynzAa6QZAR-7E=.5fc6358d-57b5-497a-8494-63a4dcd9f445@github.com>

On Thu, 19 May 2022 12:34:31 GMT, zzambers <duke at openjdk.java.net> wrote:

>> This fixes wrong paths to debuginfo files passed to zip command, causing build failure on MacOS in github workflow. Problem was introduced by JDK-8281814 [1] (integrated, while github workflow PR was still in progress). 
>> 
>> I have done some experiments [2] and found out, that on macos, debuginfo files are stored in additional directories, relative to directory where object files are stored. Removing all directory components is therefore not correct on macos. Two seemingly equivalent fixes were were considered in JDK-8281814 (using notdir and using subst), but chosen one was not the correct one.
>> 
>> Follows example which illustrates difference of different variants of said zip command:
>> 
>> **Prior to JDK-8281814:**
>> `$(ZIP) -q $$@ $$($1_DEBUGINFO_FILES)`
>> - macos:
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary space

LGTM and GHA is now happy as well.

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/61

From yan at openjdk.java.net  Tue May 24 13:05:59 2022
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Tue, 24 May 2022 13:05:59 GMT
Subject: [jdk8u-dev] Integrated: 8285727: [11u,
 17u] Unify fix for JDK-8284920 with version from head
In-Reply-To: <jeYS3grzvjV4F-0bWc_HYt3DRB4SDXvM4aUqvfZs1FI=.5fc45135-9613-428d-8015-f5ea788a203a@github.com>
References: <jeYS3grzvjV4F-0bWc_HYt3DRB4SDXvM4aUqvfZs1FI=.5fc45135-9613-428d-8015-f5ea788a203a@github.com>
Message-ID: <1UvqSh3RPFxgrtb4U86-kY16w70wihVEJmXqBidxEao=.435bfff0-fc59-48bf-95a9-5c34e16b4e4d@github.com>

On Mon, 23 May 2022 14:30:34 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> I need to backport this fix prepared by Christoph Langer to jdk8u, too. Without it, further backports using Token would be painful. The fix is not technically a backport from upstream for obvious reason so it would require review etc.

This pull request has now been integrated.

Changeset: 7961755b
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/7961755b8cd02c112ccfaceb9c20671c94a6c8e2
Stats:     132 lines in 4 files changed: 122 ins; 0 del; 10 mod

8285727: [11u, 17u] Unify fix for JDK-8284920 with version from head

Backport-of: a95482acf83cc03bc562baace0d55d831d0b2b41

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/64

From dcherepanov at openjdk.java.net  Tue May 24 13:16:49 2022
From: dcherepanov at openjdk.java.net (Dmitry Cherepanov)
Date: Tue, 24 May 2022 13:16:49 GMT
Subject: [jdk8u-dev] RFR: 8283350: (tz) Update Timezone Data to 2022a
In-Reply-To: <cRrv8SEwbWxHcO7D_ZiyYP69ilyJahxpPG1DM0GrrP4=.4a090b5c-db86-4313-a2be-162836eb6ed6@github.com>
References: <yCrjNHxq7-36uij01Ywi8jdYHoVLvflACLULiDBK8Zg=.2869debe-6b9a-4897-8296-436ee47d591f@github.com>
 <cRrv8SEwbWxHcO7D_ZiyYP69ilyJahxpPG1DM0GrrP4=.4a090b5c-db86-4313-a2be-162836eb6ed6@github.com>
Message-ID: <j_L-BAM9P80_C_f1oauWPglmIyP9sDA1unQgz0Phntk=.056d349a-de60-421c-bae6-99e11c10a345@github.com>

On Tue, 24 May 2022 12:55:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review the update to tzdata2022a
>> 
>>  - updated manually from the rearguard version (tzdata2022a-rearguard.tar.gz generated by `cd tzdb-2022a && make rearguard_tarballs`)
>>  - updated the copy of the timezone data in the test folder
>> 
>> Testing: tests for sun.util.calendar and java.time.test passed
>
> @dimitryc Please change the PR title to `Backport b05d4ccf8e54635c16bc2c26aa7a8fcc2e3b3dde` as it's a backport of that update (I see the issue is not open warning).

@jerboaa thanks, done

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/63

From duke at openjdk.java.net  Tue May 24 13:25:49 2022
From: duke at openjdk.java.net (zzambers)
Date: Tue, 24 May 2022 13:25:49 GMT
Subject: [jdk8u-dev] RFR: 8286989: Build failure on macOS after 8281814
 [v2]
In-Reply-To: <L3tbZU2tMYOLnmQmQowALakowPvcfpynzAa6QZAR-7E=.5fc6358d-57b5-497a-8494-63a4dcd9f445@github.com>
References: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>
 <lzyWO7f2gIA8m0OkcBY5MBWkNdT2RveA6P7t7-6hi_k=.a695d537-04d5-4179-a1c2-1cdcff5ea735@github.com>
 <L3tbZU2tMYOLnmQmQowALakowPvcfpynzAa6QZAR-7E=.5fc6358d-57b5-497a-8494-63a4dcd9f445@github.com>
Message-ID: <2xOr30XbbCKgXQfSnvmMw_8ku9JK4QomqNaNbWmfDuw=.5e6b0a2e-fc42-4c31-8c62-bee64277c232@github.com>

On Tue, 24 May 2022 12:58:17 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> zzambers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unnecessary space
>
> LGTM and GHA is now happy as well.

@jerboaa Thank you for review

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/61

From sgehwolf at openjdk.java.net  Tue May 24 13:28:54 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 13:28:54 GMT
Subject: [jdk8u-dev] RFR: 8283350: (tz) Update Timezone Data to 2022a
In-Reply-To: <yCrjNHxq7-36uij01Ywi8jdYHoVLvflACLULiDBK8Zg=.2869debe-6b9a-4897-8296-436ee47d591f@github.com>
References: <yCrjNHxq7-36uij01Ywi8jdYHoVLvflACLULiDBK8Zg=.2869debe-6b9a-4897-8296-436ee47d591f@github.com>
Message-ID: <UE49gc0BdZpGJKYjWIfH4FzHU8beWzZAj-EjA_KXPEA=.06bd01cc-99d9-4942-aa78-0fbcc71bade0@github.com>

On Mon, 23 May 2022 09:38:06 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Please review the update to tzdata2022a
> 
>  - updated manually from the rearguard version (tzdata2022a-rearguard.tar.gz generated by `cd tzdb-2022a && make rearguard_tarballs`)
>  - updated the copy of the timezone data in the test folder
> 
> Testing: tests for sun.util.calendar and java.time.test passed

Looks good.

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/63

From duke at openjdk.java.net  Tue May 24 13:31:00 2022
From: duke at openjdk.java.net (zzambers)
Date: Tue, 24 May 2022 13:31:00 GMT
Subject: [jdk8u-dev] Integrated: 8286989: Build failure on macOS after 8281814
In-Reply-To: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>
References: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>
Message-ID: <KCli_ZM56hwh52kDEx0fJ04XCTtMK-EiK-MiM18K5f0=.9bbea929-b691-4b31-9711-80962cb7ad15@github.com>

On Wed, 18 May 2022 17:48:08 GMT, zzambers <duke at openjdk.java.net> wrote:

> This fixes wrong paths to debuginfo files passed to zip command, causing build failure on MacOS in github workflow. Problem was introduced by JDK-8281814 [1] (integrated, while github workflow PR was still in progress). 
> 
> I have done some experiments [2] and found out, that on macos, debuginfo files are stored in additional directories, relative to directory where object files are stored. Removing all directory components is therefore not correct on macos. Two seemingly equivalent fixes were were considered in JDK-8281814 (using notdir and using subst), but chosen one was not the correct one.
> 
> Follows example which illustrates difference of different variants of said zip command:
> 
> **Prior to JDK-8281814:**
> `$(ZIP) -q $$@ $$($1_DEBUGINFO_FILES)`
> - macos:

This pull request has now been integrated.

Changeset: c5f96be5
Author:    Zdenek Zambersky <zzambers at redhat.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/c5f96be5e370f01fbb8677049e2feeeeb3b3012d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8286989: Build failure on macOS after 8281814

Reviewed-by: sgehwolf

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/61

From dcherepanov at openjdk.java.net  Tue May 24 13:54:56 2022
From: dcherepanov at openjdk.java.net (Dmitry Cherepanov)
Date: Tue, 24 May 2022 13:54:56 GMT
Subject: [jdk8u-dev] Integrated: 8283350: (tz) Update Timezone Data to 2022a
In-Reply-To: <yCrjNHxq7-36uij01Ywi8jdYHoVLvflACLULiDBK8Zg=.2869debe-6b9a-4897-8296-436ee47d591f@github.com>
References: <yCrjNHxq7-36uij01Ywi8jdYHoVLvflACLULiDBK8Zg=.2869debe-6b9a-4897-8296-436ee47d591f@github.com>
Message-ID: <0tzfqG5f7QFVP8SZnARWo1QU82A8IvoMItEL6PUHFNk=.c0b58c91-30e9-4ee7-b495-f4460e35bd91@github.com>

On Mon, 23 May 2022 09:38:06 GMT, Dmitry Cherepanov <dcherepanov at openjdk.org> wrote:

> Please review the update to tzdata2022a
> 
>  - updated manually from the rearguard version (tzdata2022a-rearguard.tar.gz generated by `cd tzdb-2022a && make rearguard_tarballs`)
>  - updated the copy of the timezone data in the test folder
> 
> Testing: tests for sun.util.calendar and java.time.test passed

This pull request has now been integrated.

Changeset: 83fbc961
Author:    Dmitry Cherepanov <dcherepanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/83fbc9612f96d3485eec2754b3b37d2f6415bd80
Stats:     214 lines in 12 files changed: 156 ins; 0 del; 58 mod

8283350: (tz) Update Timezone Data to 2022a

Reviewed-by: sgehwolf
Backport-of: b05d4ccf8e54635c16bc2c26aa7a8fcc2e3b3dde

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/63

From sgehwolf at openjdk.java.net  Tue May 24 13:59:53 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 13:59:53 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information [v2]
In-Reply-To: <oL9Gxd7o-0F0wkQPq9PNE-ebZkPFk5w2H3m37-pSNDM=.08a3c818-5486-42d7-ae58-8accb0f179a5@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
 <oL9Gxd7o-0F0wkQPq9PNE-ebZkPFk5w2H3m37-pSNDM=.08a3c818-5486-42d7-ae58-8accb0f179a5@github.com>
Message-ID: <KwzeNcWTLL0shekDNTlBMteNiuYnOibeEPdC3k5XbaE=.44c1ec80-5473-4b85-8ca3-946542eaf6e2@github.com>

On Mon, 23 May 2022 00:40:38 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> In implementing [JDK-8222975](https://bugs.openjdk.java.net/browse/JDK-8222975) and backporting [JDK-8210283](https://bugs.openjdk.java.net/browse/JDK-8210283), we have avoided backporting [JDK-8031567](https://bugs.openjdk.java.net/browse/JDK-8031567) in order to keep things simple. However, the net result has been that we have introduced [unique 8u bugs](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-April/014842.html)
>> 
>> Rather than just patching up 8u again, it seems to make sense to just bring it into line with later JDKs. There might have been a reason to keep 8u different when it was a forest of Mercurial repositories, but it is now a single Git tree like the other JDK repositories. Handling the same thing but in a unique way just makes any future backporting harder to deal with.
>> 
>> In light of this, I've now backported 8031567. I started by reverting the two 8u-specific patches, 8210283 & 8222975, and then applied 8136771 & 8031567 (which includes 8222975), along with follow-up fixes 8170385 & 8170392. 8210283 was then rebackported on top of this.
>> 
>> A couple of additional fixes were then made to workaround Makefile differences in 8u. Due to the lack of [JDK-8069261](https://bugs.openjdk.java.net/browse/JDK-8069261) the `MakeDir` usage needs to be wrapped in `eval`. 8u also doesn't have the modern macro format from  [JDK-8074988](https://bugs.openjdk.java.net/browse/JDK-8074988) and earlier fixes, so the `SetupGetRevisionForRepo` macro was modified to work in a similar way to other macros do in 8u. The stripping of `$1` is necessary to avoid it trying to create variables beginning with a space (something which led to empty variables and confused me for some time)
>> 
>> I did consider backporting those as well, but felt there were too intrusive to other areas of the build. At least we now have a template in this patch for how to convert any future instances.
>> 
>> The end result actually looks pretty straightforward and differences between this and the `make/SourceRevision.gmk` file in 11u are small.
>
> Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stray brackets

This looks OK to me. I've tested this with an tar archive as sources and works fine. Same with git.

@shiyuexw If you could test this too, I'd appreciate it. Thanks!

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From sgehwolf at openjdk.java.net  Tue May 24 13:59:54 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 13:59:54 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information [v2]
In-Reply-To: <k9jvG9QuiQzr4yLfidc2QgrmbRhukGcp7c2y-YDghD0=.1b0747e7-3b16-4274-b0e2-0924cac2b9ba@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
 <oL9Gxd7o-0F0wkQPq9PNE-ebZkPFk5w2H3m37-pSNDM=.08a3c818-5486-42d7-ae58-8accb0f179a5@github.com>
 <k9jvG9QuiQzr4yLfidc2QgrmbRhukGcp7c2y-YDghD0=.1b0747e7-3b16-4274-b0e2-0924cac2b9ba@github.com>
Message-ID: <hvBjHpaQyAUi6cKvoVZfivpOBi7-plZnk7ElOV9Wz60=.9ff5d38c-864a-4733-9f93-7b2ce2a210ec@github.com>

On Mon, 23 May 2022 00:48:35 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove stray brackets
>
> Note that this PR also updates `common/autoconf/generated-configure.sh` which was missed by #33

@gnu-andrew Could you please merge with master please, then mac os x builds should be happy too.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From sgehwolf at openjdk.java.net  Tue May 24 14:05:58 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 14:05:58 GMT
Subject: [jdk8u-dev] RFR: 8266187: Memory leak in appendBootClassPath()
In-Reply-To: <IccMfz-Oa9XSbwL2j2ezlY6QxuYxY-t7kLSbqaqCMSw=.270ffb67-1d19-4b04-9a75-abd4d89dfafb@github.com>
References: <IccMfz-Oa9XSbwL2j2ezlY6QxuYxY-t7kLSbqaqCMSw=.270ffb67-1d19-4b04-9a75-abd4d89dfafb@github.com>
Message-ID: <hW_ZDgZjtA9WeAvK_O40jAFwrkH2zlVLeyQfMx-kgLs=.5df2f979-7822-4162-b864-377d57524647@github.com>

On Tue, 19 Apr 2022 14:38:23 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Backport this patch for parity with Oracle 8u331. It fixes a memory leak 
> and risk is low,
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8266187
> Patch: https://github.com/openjdk/jdk/commit/aa90df6f51940a73f9aa078a32768855c8568034
> 
> The original patch does not apply cleanly. The conflict is copyright year line. Resolved manually.
> 
> The original code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014484.html

@zhengyu123 Please use `Backport aa90df6f51940a73f9aa078a32768855c8568034` as the PR title as this is a backport. I see a "issue not open warning" for the associated bug.

I think this can also be marked `/clean` as it's only path reshuffling from the original patch.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/42

From sgehwolf at openjdk.java.net  Tue May 24 14:09:44 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 14:09:44 GMT
Subject: [jdk8u-dev] RFR: 8260589: Crash in
 JfrTraceIdLoadBarrier::load(_jclass*)
In-Reply-To: <s3gnxE6q7VA8DMcUl6HeLBjf0La8dw6-a9mkE45tC18=.ec1f7e5b-eb11-4dc0-b593-019baa76ea28@github.com>
References: <s3gnxE6q7VA8DMcUl6HeLBjf0La8dw6-a9mkE45tC18=.ec1f7e5b-eb11-4dc0-b593-019baa76ea28@github.com>
Message-ID: <TU_H-S46DpaPV2j1NBfehdj3wZbbNMmfzcgnGrr_QJI=.36bede77-3392-46e3-ab13-9e6d03155df5@github.com>

On Mon, 18 Apr 2022 04:09:21 GMT, Long Yang <duke at openjdk.java.net> wrote:

> Hi!
> 
> Please review the backport of JDK-8260589 to 8u.
> This crash problem is easy to reproduce, so I feel it is necessary to backport it to 8u.
> 
> 3 months ago, I launched webrev and it has been reviewed by Zhengyu Gu ([the review mail link](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-March/014715.html)), thanks a lot to Zhengyu and Mario.
> Recently, I learned that the review method of 8u was changed to github, so I re-launched it in the new way.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8260589
> 11u commit: https://github.com/openjdk/jdk11u-dev/commit/1d204c554ffe969567161cc05992486ff47d346d
> Test: jdk/test/jdk/jfr/jvm/TestPrimitiveClasses.java passed.
> 
> Due to the differences between JFR in 11u and 17, Denghui made some changes when backporting this fix to 11u. 
> Denghui's changes also apply to 8u, so I directly quote Denghui's list here. (4 in total)
> 1. use MaxJfrEventId + 101 instead of LAST_TYPE_ID + 1 as the klass id of void.class
> 2. jdk 11 doesn't support jfr streaming, so I removed the call `JfrTraceIdEpoch::set_changed_tag_state()` in `load_primitive`
> 3. the Class in jdk 11 doesn't have the field 'hidden', so I removed `writer->write<bool>(false);` in `write_primitive`
> 4. there are many differences in the API of JfrTraceId between 11u and tip
> 
> In addition to the above differences, I also make supplementary explanations for the modifications I made.
> 1. The static global variable clear_artifacts in 11u was introduced by the bugfix https://bugs.openjdk.java.net/browse/JDK-8231081, but this fix has not been backported to 8u, so I removed the code related to clear_artifacts. In 8u, the metadata of the primitive types will be written into the previous chunk on every chunk rotation.
> 2. In 11u, _artifacts and _class_unload are static global variables, but in 8u, they are static member variables of JfrTypeSet, so I also made necessary changes to the functions that use these two variables.
> 
> Thanks

Please use `Backport a9d2267f8d306522522c999ff584ccaa34c46456` as the PR title so this gets properly recognized as a backport.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/36

From zgu at openjdk.java.net  Tue May 24 14:12:02 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 24 May 2022 14:12:02 GMT
Subject: [jdk8u-dev] RFR: 8266187: Memory leak in appendBootClassPath()
In-Reply-To: <hW_ZDgZjtA9WeAvK_O40jAFwrkH2zlVLeyQfMx-kgLs=.5df2f979-7822-4162-b864-377d57524647@github.com>
References: <IccMfz-Oa9XSbwL2j2ezlY6QxuYxY-t7kLSbqaqCMSw=.270ffb67-1d19-4b04-9a75-abd4d89dfafb@github.com>
 <hW_ZDgZjtA9WeAvK_O40jAFwrkH2zlVLeyQfMx-kgLs=.5df2f979-7822-4162-b864-377d57524647@github.com>
Message-ID: <qMzBqM6imxMjkXdzIlXNzUoPQAmQjOSOxhWyVkkum0s=.1a3fc244-7249-4ca2-8c32-d210f7c912eb@github.com>

On Tue, 24 May 2022 14:02:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> I think this can also be marked `/clean` as it's only path reshuffling from the original patch.

Done.

Thanks.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/42

From zgu at openjdk.java.net  Tue May 24 14:24:01 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 24 May 2022 14:24:01 GMT
Subject: [jdk8u-dev] Integrated: 8266187: Memory leak in appendBootClassPath()
In-Reply-To: <IccMfz-Oa9XSbwL2j2ezlY6QxuYxY-t7kLSbqaqCMSw=.270ffb67-1d19-4b04-9a75-abd4d89dfafb@github.com>
References: <IccMfz-Oa9XSbwL2j2ezlY6QxuYxY-t7kLSbqaqCMSw=.270ffb67-1d19-4b04-9a75-abd4d89dfafb@github.com>
Message-ID: <jK73JtkX-AIKS4kThtIJnij1qF0-QFF2vAWlezNqlho=.0cb5dcf5-5efa-4c42-a589-daea348d8a11@github.com>

On Tue, 19 Apr 2022 14:38:23 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Backport this patch for parity with Oracle 8u331. It fixes a memory leak 
> and risk is low,
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8266187
> Patch: https://github.com/openjdk/jdk/commit/aa90df6f51940a73f9aa078a32768855c8568034
> 
> The original patch does not apply cleanly. The conflict is copyright year line. Resolved manually.
> 
> The original code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014484.html

This pull request has now been integrated.

Changeset: d35dea79
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/d35dea79f48691ea280f1f8863f23113fd0c6816
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8266187: Memory leak in appendBootClassPath()

Backport-of: aa90df6f51940a73f9aa078a32768855c8568034

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/42

From mchung at openjdk.java.net  Tue May 24 17:27:01 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 24 May 2022 17:27:01 GMT
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE [v2]
In-Reply-To: <2A8v2uy4-f4H1Yi1wdhALGjBAmiSs1gZSmW6OezV1Sg=.a2c15412-1379-4a18-9b83-e1decc4c703b@github.com>
References: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
 <2A8v2uy4-f4H1Yi1wdhALGjBAmiSs1gZSmW6OezV1Sg=.a2c15412-1379-4a18-9b83-e1decc4c703b@github.com>
Message-ID: <4fOtvxshRIx2fxMaecIadEsKIpywV8_v59xgupVxWIA=.4d61f4f7-9452-45ff-95f3-b6f4aa0c7b68@github.com>

On Tue, 24 May 2022 12:41:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review these further changes for JDK 8 Maintenance Release 4 - JSR-337.
>> 
>> The MR4 changes to the reference processing implementation have made continued support for `runFinalizersonExit` unreasonable and so it is "retired" and will always throw `UnsupportedOperationException`. (This is what was also done for `Thread.stop(Throwable)` in JDK 8.)
>> 
>> Various updates to the specifications are made to remove references to running finalizers at exit - see the CSR request for details.
>> 
>> All dead code (including the already dead `JVM_Exit`) is removed. Shutdown.java is replaced by the version from mainline with a slight modification as 8u doesn't have `sun.misc.VM.isShutdown()`.
>> 
>> Tests using RFOE are deleted and a new test to check the throwing of UOE added. The new test was NOT a rename of an existing test but for some reason git is treating it that way.
>> 
>> Testing: :jdk_core group
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing paragraph tag.

Looks good.   I verified this PR matches the implementation by JDK-8198249 dropping finalization-on-exit.

hotspot/src/share/vm/runtime/thread.cpp line 3921:

> 3919:     // won't be run. Note that if a shutdown hook was registered,
> 3920:     // the Shutdown class would have already been loaded
> 3921:     // (Runtime.addShutdownHook will load it).

Nit: The comment block about "Shutdown sequence" below has a reference to finalization-on-exit.


3945           // shutdown hooks, run finalizers if finalization-on-exit

jdk/src/share/classes/java/lang/Shutdown.java line 142:

> 140:         // Synchronization is for visibility; only one thread
> 141:         // can ever get here.
> 142:         synchronized(lock) {

Suggestion:

        synchronized (lock) {


Nit: a space after `synchronized`, consistent with the style in this local file.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From phh at openjdk.java.net  Tue May 24 23:15:55 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Tue, 24 May 2022 23:15:55 GMT
Subject: [jdk8u-dev] RFR: 8202142: jfr/event/io/TestInstrumentation is
 unstable
In-Reply-To: <PeN9CCqaOiPjNwk_S--NZ6rrkR-bCZfbgFp28Kb9vlY=.6b7e0fb9-ed32-4911-b0bb-9fdcf746cea8@github.com>
References: <i99997MY_arGM_fjApfVzdmaew4SgkesOguSNb42mwE=.e9ce1b49-3f94-45fb-a68c-6d71f60002d8@github.com>
 <QekQtfc-1woi7LRM-mI5O-Pff5zYGEpTkKpLGHhPiv8=.37232abb-090d-45ee-9426-42eeaf0ee5d5@github.com>
 <PeN9CCqaOiPjNwk_S--NZ6rrkR-bCZfbgFp28Kb9vlY=.6b7e0fb9-ed32-4911-b0bb-9fdcf746cea8@github.com>
Message-ID: <eCxHTsHGYbkHM3v3H7aHv5aLSKrTNlOo908yrekxock=.b0653cc2-dce1-4e06-903b-7d0d449a7c69@github.com>

On Thu, 21 Apr 2022 02:37:53 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> I think should backport [8223396](https://bugs.openjdk.java.net/browse/JDK-8223396) first to eliminate another out-of-order backport.
>
> @zhengyu123 Could you please take another look?

@dongbohe, please add a /integrate comment so I can sponsor.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/10

From zgu at openjdk.java.net  Wed May 25 00:48:06 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 25 May 2022 00:48:06 GMT
Subject: [jdk8u-dev] RFR: 8202142: jfr/event/io/TestInstrumentation is
 unstable [v2]
In-Reply-To: <DpJNVwenZ6AWxurqfSUYK74msJZZnidY57P9No7ysoo=.1b387492-fff3-46e3-9e0d-4c68a0242737@github.com>
References: <i99997MY_arGM_fjApfVzdmaew4SgkesOguSNb42mwE=.e9ce1b49-3f94-45fb-a68c-6d71f60002d8@github.com>
 <DpJNVwenZ6AWxurqfSUYK74msJZZnidY57P9No7ysoo=.1b387492-fff3-46e3-9e0d-4c68a0242737@github.com>
Message-ID: <khd-IInmKTTWxuOx4VsRKSGGWehGiIroqZujkqA8jyw=.b4e8a74b-63d6-40c1-b266-f3f8a8236c1d@github.com>

On Fri, 25 Mar 2022 06:16:12 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> This PR has been reviewed by Paul before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014489.html
>> 
>> Thanks,
>> hedongbo
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge master
>  - 8202142: jfr/event/io/TestInstrumentation is unstable
>    
>    Backport-of: 0b9ff0c3a418070996f61f69165de02d33070f7f

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/10

From zgu at openjdk.java.net  Wed May 25 00:48:07 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 25 May 2022 00:48:07 GMT
Subject: [jdk8u-dev] RFR: 8202142: jfr/event/io/TestInstrumentation is
 unstable
In-Reply-To: <QekQtfc-1woi7LRM-mI5O-Pff5zYGEpTkKpLGHhPiv8=.37232abb-090d-45ee-9426-42eeaf0ee5d5@github.com>
References: <i99997MY_arGM_fjApfVzdmaew4SgkesOguSNb42mwE=.e9ce1b49-3f94-45fb-a68c-6d71f60002d8@github.com>
 <QekQtfc-1woi7LRM-mI5O-Pff5zYGEpTkKpLGHhPiv8=.37232abb-090d-45ee-9426-42eeaf0ee5d5@github.com>
Message-ID: <IsdNBU9cCIcGXmB6ojd0BwPi9W93_Rza4FlIXJn0RMM=.157408b8-4c7f-4d24-ba2b-046926e39833@github.com>

On Thu, 17 Mar 2022 16:19:37 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Hi,
>> 
>> This PR has been reviewed by Paul before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014489.html
>> 
>> Thanks,
>> hedongbo
>
> I think should backport [8223396](https://bugs.openjdk.java.net/browse/JDK-8223396) first to eliminate another out-of-order backport.

> @zhengyu123 Could you please take another look?

Sorry, I did not get notification somehow. LGTM

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/10

From dholmes at openjdk.java.net  Wed May 25 01:20:01 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 25 May 2022 01:20:01 GMT
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE [v2]
In-Reply-To: <4fOtvxshRIx2fxMaecIadEsKIpywV8_v59xgupVxWIA=.4d61f4f7-9452-45ff-95f3-b6f4aa0c7b68@github.com>
References: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
 <2A8v2uy4-f4H1Yi1wdhALGjBAmiSs1gZSmW6OezV1Sg=.a2c15412-1379-4a18-9b83-e1decc4c703b@github.com>
 <4fOtvxshRIx2fxMaecIadEsKIpywV8_v59xgupVxWIA=.4d61f4f7-9452-45ff-95f3-b6f4aa0c7b68@github.com>
Message-ID: <M_CQ19fIBKoJWkH8j2h23fV-8SSyZfT9i8HAozYxT_Y=.37109f2e-75a2-41a4-9e1f-fc26c0a181bb@github.com>

On Tue, 24 May 2022 16:56:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing paragraph tag.
>
> hotspot/src/share/vm/runtime/thread.cpp line 3921:
> 
>> 3919:     // won't be run. Note that if a shutdown hook was registered,
>> 3920:     // the Shutdown class would have already been loaded
>> 3921:     // (Runtime.addShutdownHook will load it).
> 
> Nit: The comment block about "Shutdown sequence" below has a reference to finalization-on-exit.
> 
> 
> 3945           // shutdown hooks, run finalizers if finalization-on-exit

Thanks, that escaped my grep search. I will fix.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From dholmes at openjdk.java.net  Wed May 25 01:23:57 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 25 May 2022 01:23:57 GMT
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE [v3]
In-Reply-To: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
References: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
Message-ID: <-fOxw5kiPBovgWHjkcoopVNO0I5HsIbNslombyYLAz4=.f025ed62-bb17-45b1-af62-7f6053df7c5c@github.com>

> Please review these further changes for JDK 8 Maintenance Release 4 - JSR-337.
> 
> The MR4 changes to the reference processing implementation have made continued support for `runFinalizersonExit` unreasonable and so it is "retired" and will always throw `UnsupportedOperationException`. (This is what was also done for `Thread.stop(Throwable)` in JDK 8.)
> 
> Various updates to the specifications are made to remove references to running finalizers at exit - see the CSR request for details.
> 
> All dead code (including the already dead `JVM_Exit`) is removed. Shutdown.java is replaced by the version from mainline with a slight modification as 8u doesn't have `sun.misc.VM.isShutdown()`.
> 
> Tests using RFOE are deleted and a new test to check the throwing of UOE added. The new test was NOT a rename of an existing test but for some reason git is treating it that way.
> 
> Testing: :jdk_core group
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Remove reference to finalizers-on-exit

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-ri/pull/9/files
  - new: https://git.openjdk.java.net/jdk8u-ri/pull/9/files/3de362a0..920e62af

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=9&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=9&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/9/head:pull/9

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From dholmes at openjdk.java.net  Wed May 25 01:26:56 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 25 May 2022 01:26:56 GMT
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE [v4]
In-Reply-To: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
References: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
Message-ID: <4kYdA0zrZx1I1MEQQUVvOFk1W0b-nu74aIsDqXHN2tI=.cab29ba1-0bc8-441e-bc69-bb21c83767a5@github.com>

> Please review these further changes for JDK 8 Maintenance Release 4 - JSR-337.
> 
> The MR4 changes to the reference processing implementation have made continued support for `runFinalizersonExit` unreasonable and so it is "retired" and will always throw `UnsupportedOperationException`. (This is what was also done for `Thread.stop(Throwable)` in JDK 8.)
> 
> Various updates to the specifications are made to remove references to running finalizers at exit - see the CSR request for details.
> 
> All dead code (including the already dead `JVM_Exit`) is removed. Shutdown.java is replaced by the version from mainline with a slight modification as 8u doesn't have `sun.misc.VM.isShutdown()`.
> 
> Tests using RFOE are deleted and a new test to check the throwing of UOE added. The new test was NOT a rename of an existing test but for some reason git is treating it that way.
> 
> Testing: :jdk_core group
> 
> Thanks,
> David

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fix style nit

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-ri/pull/9/files
  - new: https://git.openjdk.java.net/jdk8u-ri/pull/9/files/920e62af..9d064089

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=9&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=9&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/9/head:pull/9

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From dholmes at openjdk.java.net  Wed May 25 01:26:59 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 25 May 2022 01:26:59 GMT
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE [v2]
In-Reply-To: <4fOtvxshRIx2fxMaecIadEsKIpywV8_v59xgupVxWIA=.4d61f4f7-9452-45ff-95f3-b6f4aa0c7b68@github.com>
References: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
 <2A8v2uy4-f4H1Yi1wdhALGjBAmiSs1gZSmW6OezV1Sg=.a2c15412-1379-4a18-9b83-e1decc4c703b@github.com>
 <4fOtvxshRIx2fxMaecIadEsKIpywV8_v59xgupVxWIA=.4d61f4f7-9452-45ff-95f3-b6f4aa0c7b68@github.com>
Message-ID: <B5icULQOsWb8Jf238iJbwi3LVG6E7xaiuyTPiRFl-vg=.404eaed2-d046-44c4-86cb-dc7ac9c08ae6@github.com>

On Tue, 24 May 2022 17:07:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing paragraph tag.
>
> jdk/src/share/classes/java/lang/Shutdown.java line 142:
> 
>> 140:         // Synchronization is for visibility; only one thread
>> 141:         // can ever get here.
>> 142:         synchronized(lock) {
> 
> Suggestion:
> 
>         synchronized (lock) {
> 
> 
> Nit: a space after `synchronized`, consistent with the style in this local file.

Fixed.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From duke at openjdk.java.net  Wed May 25 01:36:00 2022
From: duke at openjdk.java.net (wxiang)
Date: Wed, 25 May 2022 01:36:00 GMT
Subject: [jdk8u-dev] RFR: 8287191: [8u] Build failure without git
 information
In-Reply-To: <Po5zkSTHkq4DAo3jkogTT7sCNmIyX4PybgCiaRdv79Y=.fb29bb37-fd3c-42a6-9ae7-bf447d349128@github.com>
References: <u2wL5M_3SIiF313SxhtuA2PABg6pfawV08-NU7zD-lw=.c808d94e-ec5a-4a12-93c3-6d28bbc49b00@github.com>
 <Po5zkSTHkq4DAo3jkogTT7sCNmIyX4PybgCiaRdv79Y=.fb29bb37-fd3c-42a6-9ae7-bf447d349128@github.com>
Message-ID: <shJbAaKB3SJqYaK9GqOd478b9I8yqWQLG8Pj1v1DxWE=.43eda7df-cb6e-4f72-907c-c33df47ec50e@github.com>

On Tue, 24 May 2022 12:41:47 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please see #62 which should fix this.

With the fix in #62, it can work now.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/65

From duke at openjdk.java.net  Wed May 25 01:36:05 2022
From: duke at openjdk.java.net (wxiang)
Date: Wed, 25 May 2022 01:36:05 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information [v2]
In-Reply-To: <KwzeNcWTLL0shekDNTlBMteNiuYnOibeEPdC3k5XbaE=.44c1ec80-5473-4b85-8ca3-946542eaf6e2@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
 <oL9Gxd7o-0F0wkQPq9PNE-ebZkPFk5w2H3m37-pSNDM=.08a3c818-5486-42d7-ae58-8accb0f179a5@github.com>
 <KwzeNcWTLL0shekDNTlBMteNiuYnOibeEPdC3k5XbaE=.44c1ec80-5473-4b85-8ca3-946542eaf6e2@github.com>
Message-ID: <KB0Z_kj8fuj0z1nUSSKZL8gDTJEfUvS8bAs5eli1nwk=.e87479ad-9464-4f0b-99ff-596dbd6f71bd@github.com>

On Tue, 24 May 2022 13:55:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This looks OK to me. I've tested this with an tar archive as sources and works fine. Same with git.
> 
> @shiyuexw If you could test this too, I'd appreciate it. Thanks!

I have verified it. It can work now.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From aph-open at littlepinkcloud.com  Wed May 25 08:02:03 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Wed, 25 May 2022 09:02:03 +0100
Subject: Porters: are you ready for 8284161: Implementation of Virtual Threads
 (Preview) ?
Message-ID: <b4423535-c03b-eee9-bc05-dfca0393608b@littlepinkcloud.com>

I've been trying to contact porters, but I can't get any reply on porters-dev.

Are you aware aware that the commit for 8284161 https://github.com/openjdk/jdk/pull/8166
will require changes to your port? Will you be able to fix it in time for JDK 19?
You don't have to implement virtual threads: it may only be necessary to stub some
things out, but there may be other issues as well.

Please check, and please shout out if you don't expect to get your port working
in time for JDK 19.

-- 
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 openjdk.java.net  Wed May 25 08:45:00 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 25 May 2022 08:45:00 GMT
Subject: [jdk8u-dev] RFR: 8287191: [8u] Build failure without git
 information
In-Reply-To: <u2wL5M_3SIiF313SxhtuA2PABg6pfawV08-NU7zD-lw=.c808d94e-ec5a-4a12-93c3-6d28bbc49b00@github.com>
References: <u2wL5M_3SIiF313SxhtuA2PABg6pfawV08-NU7zD-lw=.c808d94e-ec5a-4a12-93c3-6d28bbc49b00@github.com>
Message-ID: <6g6wSdTA99ete0c8_FRD1E34_q8evEFMjlPoQmjWr7Y=.dfec77fd-c95c-4181-94aa-c7b7ad0feb87@github.com>

On Tue, 24 May 2022 01:44:05 GMT, wxiang <duke at openjdk.java.net> wrote:

> In 8u332, the commit "8210283: Support git as an SCM alternative in the build? used git as an SCM.
> In the source package ?https://github.com/openjdk/jdk8u/archive/refs/tags/jdk8u332-ga.tar.gz?? 
> the .git directory has been removed in the source package. 
> 
> When we compile JDK with the source code from the package, we get the below error: 
> ``` 
> Building 'linux-x86_64-normal-server-release' (matching CONF=release)

Please close this PR then.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/65

From duke at openjdk.java.net  Wed May 25 08:45:01 2022
From: duke at openjdk.java.net (wxiang)
Date: Wed, 25 May 2022 08:45:01 GMT
Subject: [jdk8u-dev] RFR: 8287191: [8u] Build failure without git
 information
In-Reply-To: <u2wL5M_3SIiF313SxhtuA2PABg6pfawV08-NU7zD-lw=.c808d94e-ec5a-4a12-93c3-6d28bbc49b00@github.com>
References: <u2wL5M_3SIiF313SxhtuA2PABg6pfawV08-NU7zD-lw=.c808d94e-ec5a-4a12-93c3-6d28bbc49b00@github.com>
Message-ID: <bJA2GMldOqoIAA1gCnOJZIFcPnsbp9VjP6onLy_udCY=.3b72a19d-c85d-48ac-9e55-1d98843c9881@github.com>

On Tue, 24 May 2022 01:44:05 GMT, wxiang <duke at openjdk.java.net> wrote:

> In 8u332, the commit "8210283: Support git as an SCM alternative in the build? used git as an SCM.
> In the source package ?https://github.com/openjdk/jdk8u/archive/refs/tags/jdk8u332-ga.tar.gz?? 
> the .git directory has been removed in the source package. 
> 
> When we compile JDK with the source code from the package, we get the below error: 
> ``` 
> Building 'linux-x86_64-normal-server-release' (matching CONF=release)

#62 solve the issue, close this PR

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/65

From duke at openjdk.java.net  Wed May 25 08:45:02 2022
From: duke at openjdk.java.net (wxiang)
Date: Wed, 25 May 2022 08:45:02 GMT
Subject: [jdk8u-dev] Withdrawn: 8287191: [8u] Build failure without git
 information
In-Reply-To: <u2wL5M_3SIiF313SxhtuA2PABg6pfawV08-NU7zD-lw=.c808d94e-ec5a-4a12-93c3-6d28bbc49b00@github.com>
References: <u2wL5M_3SIiF313SxhtuA2PABg6pfawV08-NU7zD-lw=.c808d94e-ec5a-4a12-93c3-6d28bbc49b00@github.com>
Message-ID: <jDzQxg4HiQ2rZZ9sZEP6PHERvDM7HFTdli9BxufcvjQ=.ba9a48a7-2249-4ed5-add8-8911b93d083b@github.com>

On Tue, 24 May 2022 01:44:05 GMT, wxiang <duke at openjdk.java.net> wrote:

> In 8u332, the commit "8210283: Support git as an SCM alternative in the build? used git as an SCM.
> In the source package ?https://github.com/openjdk/jdk8u/archive/refs/tags/jdk8u332-ga.tar.gz?? 
> the .git directory has been removed in the source package. 
> 
> When we compile JDK with the source code from the package, we get the below error: 
> ``` 
> Building 'linux-x86_64-normal-server-release' (matching CONF=release)

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/65

From dongbohe at openjdk.java.net  Wed May 25 12:07:54 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Wed, 25 May 2022 12:07:54 GMT
Subject: [jdk8u-dev] Integrated: 8202142: jfr/event/io/TestInstrumentation is
 unstable
In-Reply-To: <i99997MY_arGM_fjApfVzdmaew4SgkesOguSNb42mwE=.e9ce1b49-3f94-45fb-a68c-6d71f60002d8@github.com>
References: <i99997MY_arGM_fjApfVzdmaew4SgkesOguSNb42mwE=.e9ce1b49-3f94-45fb-a68c-6d71f60002d8@github.com>
Message-ID: <eAMYzrmyc8ri0YS9VbU6SM_3rcVmsSqyP3GYZO-n7qA=.9b0d5fa5-2471-423c-b2d2-30db4060fc55@github.com>

On Thu, 17 Mar 2022 11:30:31 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> This PR has been reviewed by Paul before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014489.html
> 
> Thanks,
> hedongbo

This pull request has now been integrated.

Changeset: 2194c539
Author:    Dongbo He <dongbohe at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/2194c5399fb39fca711a6437a9f72700e951d930
Stats:     412 lines in 11 files changed: 51 ins; 37 del; 324 mod

8202142: jfr/event/io/TestInstrumentation is unstable

Reviewed-by: phh, zgu
Backport-of: 0b9ff0c3a418070996f61f69165de02d33070f7f

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/10

From andrew at openjdk.java.net  Wed May 25 16:33:06 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 25 May 2022 16:33:06 GMT
Subject: [jdk8u-dev] RFR: 8286989: Build failure on macOS after 8281814
 [v2]
In-Reply-To: <lzyWO7f2gIA8m0OkcBY5MBWkNdT2RveA6P7t7-6hi_k=.a695d537-04d5-4179-a1c2-1cdcff5ea735@github.com>
References: <5gqpJuKZpfa60oatsQMcYEx-9ML95N6No-v1sAig5Js=.5b852e43-4d22-43d6-baa5-b6446e842774@github.com>
 <lzyWO7f2gIA8m0OkcBY5MBWkNdT2RveA6P7t7-6hi_k=.a695d537-04d5-4179-a1c2-1cdcff5ea735@github.com>
Message-ID: <qYoZftWu0uOmq5dz4GDkKFl9VWrRwAujfIrPHTcZ0FA=.1d2b7561-705b-4e7d-8593-864d4c4c1c10@github.com>

On Thu, 19 May 2022 12:34:31 GMT, zzambers <duke at openjdk.java.net> wrote:

>> This fixes wrong paths to debuginfo files passed to zip command, causing build failure on MacOS in github workflow. Problem was introduced by JDK-8281814 [1] (integrated, while github workflow PR was still in progress). 
>> 
>> I have done some experiments [2] and found out, that on macos, debuginfo files are stored in additional directories, relative to directory where object files are stored. Removing all directory components is therefore not correct on macos. Two seemingly equivalent fixes were were considered in JDK-8281814 (using notdir and using subst), but chosen one was not the correct one.
>> 
>> Follows example which illustrates difference of different variants of said zip command:
>> 
>> **Prior to JDK-8281814:**
>> `$(ZIP) -q $$@ $$($1_DEBUGINFO_FILES)`
>> - macos:
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary space

Yes, I identified the same thing here: https://github.com/openjdk/jdk8u-dev/pull/26#issuecomment-1125614736

I thought we might need more of the NativeCompilation.gmk changes from https://hg.openjdk.java.net/jdk9/jdk9/rev/278f9a9e9329 (https://bugs.openjdk.java.net/browse/JDK-8150736) but it seems most of it was integrated in https://bugs.openjdk.java.net/browse/JDK-8262730

Anyway, thanks for getting this in. I was worried this wasn't going to be fixed before rampdown.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/61

From andrew at openjdk.java.net  Wed May 25 16:37:19 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 25 May 2022 16:37:19 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information [v3]
In-Reply-To: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
Message-ID: <7NhBzHOrTn_9a65XVBgOC6f3SmnQjsAeod2A1HEwzj8=.1ca82e1e-a176-4b6c-97c5-9f57662d7719@github.com>

> In implementing [JDK-8222975](https://bugs.openjdk.java.net/browse/JDK-8222975) and backporting [JDK-8210283](https://bugs.openjdk.java.net/browse/JDK-8210283), we have avoided backporting [JDK-8031567](https://bugs.openjdk.java.net/browse/JDK-8031567) in order to keep things simple. However, the net result has been that we have introduced [unique 8u bugs](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-April/014842.html)
> 
> Rather than just patching up 8u again, it seems to make sense to just bring it into line with later JDKs. There might have been a reason to keep 8u different when it was a forest of Mercurial repositories, but it is now a single Git tree like the other JDK repositories. Handling the same thing but in a unique way just makes any future backporting harder to deal with.
> 
> In light of this, I've now backported 8031567. I started by reverting the two 8u-specific patches, 8210283 & 8222975, and then applied 8136771 & 8031567 (which includes 8222975), along with follow-up fixes 8170385 & 8170392. 8210283 was then rebackported on top of this.
> 
> A couple of additional fixes were then made to workaround Makefile differences in 8u. Due to the lack of [JDK-8069261](https://bugs.openjdk.java.net/browse/JDK-8069261) the `MakeDir` usage needs to be wrapped in `eval`. 8u also doesn't have the modern macro format from  [JDK-8074988](https://bugs.openjdk.java.net/browse/JDK-8074988) and earlier fixes, so the `SetupGetRevisionForRepo` macro was modified to work in a similar way to other macros do in 8u. The stripping of `$1` is necessary to avoid it trying to create variables beginning with a space (something which led to empty variables and confused me for some time)
> 
> I did consider backporting those as well, but felt there were too intrusive to other areas of the build. At least we now have a template in this patch for how to convert any future instances.
> 
> The end result actually looks pretty straightforward and differences between this and the `make/SourceRevision.gmk` file in 11u are small.

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

 - Merge remote-tracking branch 'jdk8u-dev/master' into JDK-8031567
 - Remove stray brackets
 - Fix SetupGetRevisionForRepo to workaround lack of JDK-8074988
 - Use eval wrapper for MakeDir calls due to lack of JDK-8069261
 - 8210283: Support git as an SCM alternative in the build
 - 8170392: JDK-8031567 broke builds from source bundles
 - 8170385: JDK-8031567 broke source bundles
 - 8031567: Better model for storing source revision information
 - 8136771: Implement the license-swap logic as a make target
 - Revert "8222975: Fix 'release' file to reflect actual repo checkin used to compile JDK"
   
   This reverts commit 2f2cc4c4710af7c88e8f87bf4aca9eef29329082.
 - ... and 1 more: https://git.openjdk.java.net/jdk8u-dev/compare/d06dffa1...4ce1240c

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/62/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/62/files/3f4af272..4ce1240c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=62&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=62&range=01-02

  Stats: 828 lines in 36 files changed: 373 ins; 43 del; 412 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/62.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/62/head:pull/62

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From andrew at openjdk.java.net  Wed May 25 16:37:21 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 25 May 2022 16:37:21 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information [v2]
In-Reply-To: <oL9Gxd7o-0F0wkQPq9PNE-ebZkPFk5w2H3m37-pSNDM=.08a3c818-5486-42d7-ae58-8accb0f179a5@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
 <oL9Gxd7o-0F0wkQPq9PNE-ebZkPFk5w2H3m37-pSNDM=.08a3c818-5486-42d7-ae58-8accb0f179a5@github.com>
Message-ID: <ZRe6BGlQObev_4taJ-GWNbeCMa7IXBO46pB-YMaCXlw=.06fe4545-4170-47c4-8b6e-4d77c9a0d3fc@github.com>

On Mon, 23 May 2022 00:40:38 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> In implementing [JDK-8222975](https://bugs.openjdk.java.net/browse/JDK-8222975) and backporting [JDK-8210283](https://bugs.openjdk.java.net/browse/JDK-8210283), we have avoided backporting [JDK-8031567](https://bugs.openjdk.java.net/browse/JDK-8031567) in order to keep things simple. However, the net result has been that we have introduced [unique 8u bugs](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-April/014842.html)
>> 
>> Rather than just patching up 8u again, it seems to make sense to just bring it into line with later JDKs. There might have been a reason to keep 8u different when it was a forest of Mercurial repositories, but it is now a single Git tree like the other JDK repositories. Handling the same thing but in a unique way just makes any future backporting harder to deal with.
>> 
>> In light of this, I've now backported 8031567. I started by reverting the two 8u-specific patches, 8210283 & 8222975, and then applied 8136771 & 8031567 (which includes 8222975), along with follow-up fixes 8170385 & 8170392. 8210283 was then rebackported on top of this.
>> 
>> A couple of additional fixes were then made to workaround Makefile differences in 8u. Due to the lack of [JDK-8069261](https://bugs.openjdk.java.net/browse/JDK-8069261) the `MakeDir` usage needs to be wrapped in `eval`. 8u also doesn't have the modern macro format from  [JDK-8074988](https://bugs.openjdk.java.net/browse/JDK-8074988) and earlier fixes, so the `SetupGetRevisionForRepo` macro was modified to work in a similar way to other macros do in 8u. The stripping of `$1` is necessary to avoid it trying to create variables beginning with a space (something which led to empty variables and confused me for some time)
>> 
>> I did consider backporting those as well, but felt there were too intrusive to other areas of the build. At least we now have a template in this patch for how to convert any future instances.
>> 
>> The end result actually looks pretty straightforward and differences between this and the `make/SourceRevision.gmk` file in 11u are small.
>
> Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove stray brackets

Rebased. That should hopefully fix the Windows weirdness too.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From andrew at openjdk.java.net  Wed May 25 17:20:03 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 25 May 2022 17:20:03 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information [v2]
In-Reply-To: <hvBjHpaQyAUi6cKvoVZfivpOBi7-plZnk7ElOV9Wz60=.9ff5d38c-864a-4733-9f93-7b2ce2a210ec@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
 <oL9Gxd7o-0F0wkQPq9PNE-ebZkPFk5w2H3m37-pSNDM=.08a3c818-5486-42d7-ae58-8accb0f179a5@github.com>
 <k9jvG9QuiQzr4yLfidc2QgrmbRhukGcp7c2y-YDghD0=.1b0747e7-3b16-4274-b0e2-0924cac2b9ba@github.com>
 <hvBjHpaQyAUi6cKvoVZfivpOBi7-plZnk7ElOV9Wz60=.9ff5d38c-864a-4733-9f93-7b2ce2a210ec@github.com>
Message-ID: <zMlYAxnC77V7rWNIT80p3UWigNnc5rYmN5tibPicjAc=.a8b33c78-aa0d-4273-858a-fca39ce82d6d@github.com>

On Tue, 24 May 2022 13:56:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Note that this PR also updates `common/autoconf/generated-configure.sh` which was missed by #33
>
> @gnu-andrew Could you please merge with master please, then mac os x builds should be happy too.

@jerboaa I've flagged the bug with `jdk8u-fix-request`

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From alitvinov at openjdk.java.net  Wed May 25 17:24:47 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Wed, 25 May 2022 17:24:47 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components
In-Reply-To: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
Message-ID: <XDWRkDBgQBcG_FaxVEccOoKX-EJykfr7zEisq9rkUDY=.94cf254c-7613-432c-b40e-338a0beb11ee@github.com>

On Tue, 17 May 2022 18:31:23 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
> The original patch applied not cleanly due to 2 files:
>    
> 
>>  MotifLookAndFeel.java - differences in the header and in the context;
>>  SwingUtilities2.java - difference in the context.
> 
> Tested on Windows. All regular tests passed.

Hello Olga,

The backport of the fix for the bug JDK-8194873 itself looks correct. When I did backport of this fix, I experienced failure of the regression test "test/jdk/javax/swing/event/RightAltKeyTest.java" to resolve which it was necessary to backport the fix for the bug JDK-8155742. Does the test "test/jdk/javax/swing/event/RightAltKeyTest.java" pass successfully in your case with this backport fix?

Thank you,
Anton

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From duke at openjdk.java.net  Wed May 25 17:51:56 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 25 May 2022 17:51:56 GMT
Subject: [jdk8u-dev] Withdrawn: 8146523:
 VirtualMemoryTracker::remove_released_region double count unmapped CDS shared
 memory
In-Reply-To: <MxXCxAlYTUYPneBHRMIpj6SaCUoNd9mxWOVRRj2iiQQ=.202b28f3-cea2-46ba-ba51-e58a64d268fb@github.com>
References: <MxXCxAlYTUYPneBHRMIpj6SaCUoNd9mxWOVRRj2iiQQ=.202b28f3-cea2-46ba-ba51-e58a64d268fb@github.com>
Message-ID: <dK2jqawcOfyOUwTxtankYvwLjBTEgQwmmLl1vfOsz9M=.c839d8d4-3b9a-4b30-92c6-6c4b83e1fed7@github.com>

On Wed, 30 Mar 2022 11:21:28 GMT, wxiang <duke at openjdk.java.net> wrote:

> 8146523: VirtualMemoryTracker::remove_released_region double count unmapped CDS shared memory
> Skip tracking release for unmapped CDS shared space.
> 
> JDK8u can reproduce this prolbem in some special case, for example the timestamp of jar file in jdk build is changed. 
> 
> To reproduce the issue with JDK8: 
> 1. Dump class list? java -XX:DumpLoadedClassList=my.list -version 
> 2. Generate jsa?java -XX:+UnlockDiagnosticVMOptions -Xshare:dump -XX:SharedClassListFile=my.list -XX:SharedArchiveFile=my.jsa 
> 3. Touch some jar files in JDK build? touch jre/lib/resources.jar eg 
> 4. Run with the jsa:java -XX:+UnlockDiagnosticVMOptions -Xshare:on -XX:SharedArchiveFile=nmt_version.jsa -XX:NativeMemoryTracking=summary -XX:-RequireSharedSpaces -version 
> 
> Then crash as below: 
> 
> # 
> # A fatal error has been detected by the Java Runtime Environment: 
> # 
> # SIGSEGV (0xb) at pc=0x00007fc08dee0195, pid=21887, tid=0x00007fc08f024700 
> # 
> # JRE version: (8.0_322-b06) (build ) 
> # Java VM: OpenJDK 64-Bit Server VM (25.322-b06 mixed mode linux-amd64 compressed oops) 
> # Problematic frame: 
> # V [libjvm.so+0xb32195] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x1a5 
> # 
> # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again 
> # 
> # An error report file with more information is saved as: 
> # /data/work/test/nmtissue/hs_err_pid21887.log 
> # 
> # If you would like to submit a bug report, please visit: 
> # https://github.com/adoptium/adoptium-support/issues 
> # 
> 
> To solve the issue, we?d like to back port this fix to jdk8u

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/27

From andrew at openjdk.java.net  Thu May 26 00:36:51 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 26 May 2022 00:36:51 GMT
Subject: [jdk8u-dev] RFR: 8031567: Better model for storing source revision
 information [v3]
In-Reply-To: <7NhBzHOrTn_9a65XVBgOC6f3SmnQjsAeod2A1HEwzj8=.1ca82e1e-a176-4b6c-97c5-9f57662d7719@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
 <7NhBzHOrTn_9a65XVBgOC6f3SmnQjsAeod2A1HEwzj8=.1ca82e1e-a176-4b6c-97c5-9f57662d7719@github.com>
Message-ID: <EE0b5ww8hNe8XD_-Y8WEIQoJXvTyFnuGoUglK3-M5_8=.629e0095-3e53-4831-9043-b588a34abe18@github.com>

On Wed, 25 May 2022 16:37:19 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> In implementing [JDK-8222975](https://bugs.openjdk.java.net/browse/JDK-8222975) and backporting [JDK-8210283](https://bugs.openjdk.java.net/browse/JDK-8210283), we have avoided backporting [JDK-8031567](https://bugs.openjdk.java.net/browse/JDK-8031567) in order to keep things simple. However, the net result has been that we have introduced [unique 8u bugs](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-April/014842.html)
>> 
>> Rather than just patching up 8u again, it seems to make sense to just bring it into line with later JDKs. There might have been a reason to keep 8u different when it was a forest of Mercurial repositories, but it is now a single Git tree like the other JDK repositories. Handling the same thing but in a unique way just makes any future backporting harder to deal with.
>> 
>> In light of this, I've now backported 8031567. I started by reverting the two 8u-specific patches, 8210283 & 8222975, and then applied 8136771 & 8031567 (which includes 8222975), along with follow-up fixes 8170385 & 8170392. 8210283 was then rebackported on top of this.
>> 
>> A couple of additional fixes were then made to workaround Makefile differences in 8u. Due to the lack of [JDK-8069261](https://bugs.openjdk.java.net/browse/JDK-8069261) the `MakeDir` usage needs to be wrapped in `eval`. 8u also doesn't have the modern macro format from  [JDK-8074988](https://bugs.openjdk.java.net/browse/JDK-8074988) and earlier fixes, so the `SetupGetRevisionForRepo` macro was modified to work in a similar way to other macros do in 8u. The stripping of `$1` is necessary to avoid it trying to create variables beginning with a space (something which led to empty variables and confused me for some time)
>> 
>> I did consider backporting those as well, but felt there were too intrusive to other areas of the build. At least we now have a template in this patch for how to convert any future instances.
>> 
>> The end result actually looks pretty straightforward and differences between this and the `make/SourceRevision.gmk` file in 11u are small.
>
> Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk8u-dev/master' into JDK-8031567
>  - Remove stray brackets
>  - Fix SetupGetRevisionForRepo to workaround lack of JDK-8074988
>  - Use eval wrapper for MakeDir calls due to lack of JDK-8069261
>  - 8210283: Support git as an SCM alternative in the build
>  - 8170392: JDK-8031567 broke builds from source bundles
>  - 8170385: JDK-8031567 broke source bundles
>  - 8031567: Better model for storing source revision information
>  - 8136771: Implement the license-swap logic as a make target
>  - Revert "8222975: Fix 'release' file to reflect actual repo checkin used to compile JDK"
>    
>    This reverts commit 2f2cc4c4710af7c88e8f87bf4aca9eef29329082.
>  - ... and 1 more: https://git.openjdk.java.net/jdk8u-dev/compare/52289bf8...4ce1240c

I see `jdk8u-fix-yes`.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From andrew at openjdk.java.net  Thu May 26 00:39:00 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 26 May 2022 00:39:00 GMT
Subject: [jdk8u-dev] Integrated: 8031567: Better model for storing source
 revision information
In-Reply-To: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
References: <zTNVeY5MnWBe8ONbr1HBL6rz0aoCFQD5tJRpJshnDxw=.a3b5df76-3dd8-4ab8-b8b7-bde04c4f7532@github.com>
Message-ID: <sFATCyf9l4KCGdxdPDOz1VwOkYCuEp_6mEd9QtKS6gw=.c78d2dfa-466d-48e3-8f27-fdc52c323385@github.com>

On Mon, 23 May 2022 00:24:22 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> In implementing [JDK-8222975](https://bugs.openjdk.java.net/browse/JDK-8222975) and backporting [JDK-8210283](https://bugs.openjdk.java.net/browse/JDK-8210283), we have avoided backporting [JDK-8031567](https://bugs.openjdk.java.net/browse/JDK-8031567) in order to keep things simple. However, the net result has been that we have introduced [unique 8u bugs](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-April/014842.html)
> 
> Rather than just patching up 8u again, it seems to make sense to just bring it into line with later JDKs. There might have been a reason to keep 8u different when it was a forest of Mercurial repositories, but it is now a single Git tree like the other JDK repositories. Handling the same thing but in a unique way just makes any future backporting harder to deal with.
> 
> In light of this, I've now backported 8031567. I started by reverting the two 8u-specific patches, 8210283 & 8222975, and then applied 8136771 & 8031567 (which includes 8222975), along with follow-up fixes 8170385 & 8170392. 8210283 was then rebackported on top of this.
> 
> A couple of additional fixes were then made to workaround Makefile differences in 8u. Due to the lack of [JDK-8069261](https://bugs.openjdk.java.net/browse/JDK-8069261) the `MakeDir` usage needs to be wrapped in `eval`. 8u also doesn't have the modern macro format from  [JDK-8074988](https://bugs.openjdk.java.net/browse/JDK-8074988) and earlier fixes, so the `SetupGetRevisionForRepo` macro was modified to work in a similar way to other macros do in 8u. The stripping of `$1` is necessary to avoid it trying to create variables beginning with a space (something which led to empty variables and confused me for some time)
> 
> I did consider backporting those as well, but felt there were too intrusive to other areas of the build. At least we now have a template in this patch for how to convert any future instances.
> 
> The end result actually looks pretty straightforward and differences between this and the `make/SourceRevision.gmk` file in 11u are small.

This pull request has now been integrated.

Changeset: e3b9a06a
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/e3b9a06ab885289e943167935912b42ab53244e3
Stats:     267 lines in 13 files changed: 190 ins; 45 del; 32 mod

8031567: Better model for storing source revision information
8170385: JDK-8031567 broke source bundles
8170392: JDK-8031567 broke builds from source bundles

Reviewed-by: sgehwolf
Backport-of: 27b7ab8b27a5548ed4cd823d35c8190a594bfdd1

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/62

From iris at openjdk.java.net  Fri May 27 05:58:44 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 27 May 2022 05:58:44 GMT
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE [v4]
In-Reply-To: <4kYdA0zrZx1I1MEQQUVvOFk1W0b-nu74aIsDqXHN2tI=.cab29ba1-0bc8-441e-bc69-bb21c83767a5@github.com>
References: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
 <4kYdA0zrZx1I1MEQQUVvOFk1W0b-nu74aIsDqXHN2tI=.cab29ba1-0bc8-441e-bc69-bb21c83767a5@github.com>
Message-ID: <VymlvLdW9--v5VO0d0aN6mrtJsIYArXFr77bwoSdW7Y=.4fbb5030-be06-4d41-b017-8af99523c89f@github.com>

On Wed, 25 May 2022 01:26:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review these further changes for JDK 8 Maintenance Release 4 - JSR-337.
>> 
>> The MR4 changes to the reference processing implementation have made continued support for `runFinalizersonExit` unreasonable and so it is "retired" and will always throw `UnsupportedOperationException`. (This is what was also done for `Thread.stop(Throwable)` in JDK 8.)
>> 
>> Various updates to the specifications are made to remove references to running finalizers at exit - see the CSR request for details.
>> 
>> All dead code (including the already dead `JVM_Exit`) is removed. Shutdown.java is replaced by the version from mainline with a slight modification as 8u doesn't have `sun.misc.VM.isShutdown()`.
>> 
>> Tests using RFOE are deleted and a new test to check the throwing of UOE added. The new test was NOT a rename of an existing test but for some reason git is treating it that way.
>> 
>> Testing: :jdk_core group
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix style nit

Spec changes in java.lang.{Runtime,Shutdown,System} align with CSR 8287133 and are as expected.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From ecki at zusammenkunft.net  Fri May 27 09:56:43 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 27 May 2022 09:56:43 +0000
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE [v4]
In-Reply-To: <VymlvLdW9--v5VO0d0aN6mrtJsIYArXFr77bwoSdW7Y=.4fbb5030-be06-4d41-b017-8af99523c89f@github.com>
References: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
 <4kYdA0zrZx1I1MEQQUVvOFk1W0b-nu74aIsDqXHN2tI=.cab29ba1-0bc8-441e-bc69-bb21c83767a5@github.com>
 <VymlvLdW9--v5VO0d0aN6mrtJsIYArXFr77bwoSdW7Y=.4fbb5030-be06-4d41-b017-8af99523c89f@github.com>
Message-ID: <AM8P193MB1138064EB45D2312EEBE99F5FFD89@AM8P193MB1138.EURP193.PROD.OUTLOOK.COM>

Hello,

Can I ask a stupid question? How is this planned to float back to the updates project and the openjdk8 distributions which are out there?

 I could imagine this has the potential to break existing programs if symbols get removed or if a function throws an exception. I would not expect such a removal in a version which is in maintenance. What am I understand here wrong? Why such maintenance releases to the 8u version anyway?

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> im Auftrag von Iris Clark <iris at openjdk.java.net>
Gesendet: Friday, May 27, 2022 7:58:44 AM
An: jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Betreff: Re: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so that it always throws UOE [v4]

On Wed, 25 May 2022 01:26:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review these further changes for JDK 8 Maintenance Release 4 - JSR-337.
>>
>> The MR4 changes to the reference processing implementation have made continued support for `runFinalizersonExit` unreasonable and so it is "retired" and will always throw `UnsupportedOperationException`. (This is what was also done for `Thread.stop(Throwable)` in JDK 8.)
>>
>> Various updates to the specifications are made to remove references to running finalizers at exit - see the CSR request for details.
>>
>> All dead code (including the already dead `JVM_Exit`) is removed. Shutdown.java is replaced by the version from mainline with a slight modification as 8u doesn't have `sun.misc.VM.isShutdown()`.
>>
>> Tests using RFOE are deleted and a new test to check the throwing of UOE added. The new test was NOT a rename of an existing test but for some reason git is treating it that way.
>>
>> Testing: :jdk_core group
>>
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>
>   Fix style nit

Spec changes in java.lang.{Runtime,Shutdown,System} align with CSR 8287133 and are as expected.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From mchung at openjdk.java.net  Fri May 27 17:13:46 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 27 May 2022 17:13:46 GMT
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE [v4]
In-Reply-To: <4kYdA0zrZx1I1MEQQUVvOFk1W0b-nu74aIsDqXHN2tI=.cab29ba1-0bc8-441e-bc69-bb21c83767a5@github.com>
References: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
 <4kYdA0zrZx1I1MEQQUVvOFk1W0b-nu74aIsDqXHN2tI=.cab29ba1-0bc8-441e-bc69-bb21c83767a5@github.com>
Message-ID: <L0l8E5sfTGEU6PLXUNMCV2IAcot48r5x9Mzk4Ccf9y4=.5d3a49d2-e2eb-4ecf-bd29-21f997d4372c@github.com>

On Wed, 25 May 2022 01:26:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review these further changes for JDK 8 Maintenance Release 4 - JSR-337.
>> 
>> The MR4 changes to the reference processing implementation have made continued support for `runFinalizersonExit` unreasonable and so it is "retired" and will always throw `UnsupportedOperationException`. (This is what was also done for `Thread.stop(Throwable)` in JDK 8.)
>> 
>> Various updates to the specifications are made to remove references to running finalizers at exit - see the CSR request for details.
>> 
>> All dead code (including the already dead `JVM_Exit`) is removed. Shutdown.java is replaced by the version from mainline with a slight modification as 8u doesn't have `sun.misc.VM.isShutdown()`.
>> 
>> Tests using RFOE are deleted and a new test to check the throwing of UOE added. The new test was NOT a rename of an existing test but for some reason git is treating it that way.
>> 
>> Testing: :jdk_core group
>> 
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix style nit

As described in CSR 8287133, `Runtime.runFinalizersOnExit` was removed from Java 11 in 2018.   We did the corpus analysis at that time showed very few uses, and most of those were gone in later versions of the same software. A rerun of the corpus analysis done in 2022 found only a single direct use of `runFinalizersOnExit` and that was only in non-product builds.  It is believed that retiring `Runtime.runFinalizersOnExit` will have minimal real world impact.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From iris.clark at oracle.com  Fri May 27 17:28:35 2022
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 27 May 2022 17:28:35 +0000
Subject: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE [v4]
In-Reply-To: <AM8P193MB1138064EB45D2312EEBE99F5FFD89@AM8P193MB1138.EURP193.PROD.OUTLOOK.COM>
References: <Ok30rZBWM_0e_HSQGA6fdBiav8zb-GKVRhRkwpJTDSI=.610fb9c0-696a-4b9d-bd38-36fb65c8c955@github.com>
 <4kYdA0zrZx1I1MEQQUVvOFk1W0b-nu74aIsDqXHN2tI=.cab29ba1-0bc8-441e-bc69-bb21c83767a5@github.com>
 <VymlvLdW9--v5VO0d0aN6mrtJsIYArXFr77bwoSdW7Y=.4fbb5030-be06-4d41-b017-8af99523c89f@github.com>
 <AM8P193MB1138064EB45D2312EEBE99F5FFD89@AM8P193MB1138.EURP193.PROD.OUTLOOK.COM>
Message-ID: <SJ0PR10MB5440409AD2B6D53149D346D1FBD89@SJ0PR10MB5440.namprd10.prod.outlook.com>

Hi, Bernd.

> How is this planned to float back to the updates project and the openjdk8 distributions which are out there?

After the MRel is delivered in Jul, the changes will be pushed to github.com/openjdk/jdk8u-dev which will be collecting changes for the October Security Release.  The changes will also be delivered into Oracle's Oct CPU release.

Thanks,
Iris

________________________________
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Bernd Eckenfels <ecki at zusammenkunft.net>
Sent: Friday, May 27, 2022 2:56 AM
To: jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject: Re: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so that it always throws UOE [v4]

Hello,

Can I ask a stupid question? How is this planned to float back to the updates project and the openjdk8 distributions which are out there?

 I could imagine this has the potential to break existing programs if symbols get removed or if a function throws an exception. I would not expect such a removal in a version which is in maintenance. What am I understand here wrong? Why such maintenance releases to the 8u version anyway?

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> im Auftrag von Iris Clark <iris at openjdk.java.net>
Gesendet: Friday, May 27, 2022 7:58:44 AM
An: jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Betreff: Re: [jdk8u-ri] RFR: 8287132: Retire Runtime.runFinalizersOnExit so that it always throws UOE [v4]

On Wed, 25 May 2022 01:26:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review these further changes for JDK 8 Maintenance Release 4 - JSR-337.
>>
>> The MR4 changes to the reference processing implementation have made continued support for `runFinalizersonExit` unreasonable and so it is "retired" and will always throw `UnsupportedOperationException`. (This is what was also done for `Thread.stop(Throwable)` in JDK 8.)
>>
>> Various updates to the specifications are made to remove references to running finalizers at exit - see the CSR request for details.
>>
>> All dead code (including the already dead `JVM_Exit`) is removed. Shutdown.java is replaced by the version from mainline with a slight modification as 8u doesn't have `sun.misc.VM.isShutdown()`.
>>
>> Tests using RFOE are deleted and a new test to check the throwing of UOE added. The new test was NOT a rename of an existing test but for some reason git is treating it that way.
>>
>> Testing: :jdk_core group
>>
>> Thanks,
>> David
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>
>   Fix style nit

Spec changes in java.lang.{Runtime,Shutdown,System} align with CSR 8287133 and are as expected.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/9

From omikhaltcova at openjdk.java.net  Fri May 27 22:48:06 2022
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 27 May 2022 22:48:06 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v2]
In-Reply-To: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
Message-ID: <WsZTJ5SHsrGIYtxEqzW0quurfy1w2TJbbwqObCJXjkA=.68bfb48b-d1f7-4cc1-b0e8-d12340c2601f@github.com>

> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
> The original patch applied not cleanly due to 2 files:
>    
> 
>>  MotifLookAndFeel.java - differences in the header and in the context;
>>  SwingUtilities2.java - difference in the context.
> 
> Tested on Windows. All regular tests passed.

Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:

  Moved RightAltKeyTest.java to the correct location

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/60/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/60/files/85b13c58..ccc0df0f

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

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/60.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/60/head:pull/60

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From omikhaltcova at openjdk.java.net  Fri May 27 22:52:33 2022
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 27 May 2022 22:52:33 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v3]
In-Reply-To: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
Message-ID: <5CUmyq8nA8jgVNiiK-SDNsJ5-gRtiXnOjg4Ou2L68NA=.1a7fa449-f248-409a-9a8d-6c2dee31823f@github.com>

> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
> The original patch applied not cleanly due to 2 files:
>    
> 
>>  MotifLookAndFeel.java - differences in the header and in the context;
>>  SwingUtilities2.java - difference in the context.
> 
> Tested on Windows. All regular tests passed.

Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:

  Deleted RightAltKeyTest.java from the wrong location

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/60/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/60/files/ccc0df0f..bcb79d5c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=60&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=60&range=01-02

  Stats: 269 lines in 1 file changed: 0 ins; 269 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/60.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/60/head:pull/60

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From omikhaltcova at openjdk.java.net  Fri May 27 23:13:46 2022
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 27 May 2022 23:13:46 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v3]
In-Reply-To: <5CUmyq8nA8jgVNiiK-SDNsJ5-gRtiXnOjg4Ou2L68NA=.1a7fa449-f248-409a-9a8d-6c2dee31823f@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
 <5CUmyq8nA8jgVNiiK-SDNsJ5-gRtiXnOjg4Ou2L68NA=.1a7fa449-f248-409a-9a8d-6c2dee31823f@github.com>
Message-ID: <6PaCErABdsSD0HcsVZKKB2oIrudLWaceqgEtNYM_FUg=.5cf97032-f1eb-429a-8ec2-c657d813bb3d@github.com>

On Fri, 27 May 2022 22:52:33 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
>> The original patch applied not cleanly due to 2 files:
>>    
>> 
>>>  MotifLookAndFeel.java - differences in the header and in the context;
>>>  SwingUtilities2.java - difference in the context.
>> 
>> Tested on Windows. All regular tests passed.
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Deleted RightAltKeyTest.java from the wrong location

Hi Anton,
RightAltKeyTest.java got to the wrong place after applying the patch. That's why I didn't notice its failure while running the automated testing. 
Moved RightAltKeyTest.java from
` test/jdk/javax/swing/event/RightAltKeyTest.java`
to
` jdk/test/javax/swing/event/RightAltKeyTest.java`
Now I see this failure. Thanks!

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From omikhaltcova at openjdk.java.net  Sat May 28 00:22:03 2022
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Sat, 28 May 2022 00:22:03 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v4]
In-Reply-To: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
Message-ID: <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>

> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
> The original patch applied not cleanly due to 2 files:
>    
> 
>>  MotifLookAndFeel.java - differences in the header and in the context;
>>  SwingUtilities2.java - difference in the context.
> 
> Tested on Windows. All regular tests passed.

Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:

  Backport 08482543b496efa11dc8084a14a831799de60a93

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/60/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/60/files/bcb79d5c..ace410e2

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

  Stats: 30 lines in 4 files changed: 13 ins; 5 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/60.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/60/head:pull/60

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From omikhaltcova at openjdk.java.net  Sat May 28 00:51:36 2022
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Sat, 28 May 2022 00:51:36 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v4]
In-Reply-To: <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
 <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>
Message-ID: <N3LU7te59wpqkWSu7Z6eKDiR8yi5sseTmo7yDgqVDws=.fd50924b-f273-4b93-af35-940264de8548@github.com>

On Sat, 28 May 2022 00:22:03 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
>> The original patch for JDK-8194873 applied not cleanly due to 2 files:   
>>>  MotifLookAndFeel.java - differences in the header and in the context;
>>>  SwingUtilities2.java - difference in the context.
>> 
>> The backport for JDK-8155742
>> 
>> 8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows
>> 
>> was included as a part of this patch due to dependency on it of the regression test "jdk/test/javax/swing/event/RightAltKeyTest.java" included into the patch for JDK-8194873 (this test fails without the patch for JDK-8155742 as was pointed out below by Anton Litvinov).
>> The original patch For JDK-8155742 applied not cleanly due to 1 file:
>>> AltGraphModifierTest.java - differences in the header and slight in the context.
>> 
>> Tested on Windows. All regular tests passed.
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backport 08482543b496efa11dc8084a14a831799de60a93

The backport for JDK-8155742 fixes the failure of the regression test "jdk/test/javax/swing/event/RightAltKeyTest.java".

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From andrew at openjdk.java.net  Sun May 29 15:05:55 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Sun, 29 May 2022 15:05:55 GMT
Subject: [jdk8u-dev] RFR: 8173361: various crashes in
 JvmtiExport::post_compiled_method_load
In-Reply-To: <XYwkEcOZQzAj1pJk9SBS6SO4GG90ETqkVbZaWlkM4ME=.530b79e3-d82f-40c3-a553-46ea1a5377f8@github.com>
References: <XYwkEcOZQzAj1pJk9SBS6SO4GG90ETqkVbZaWlkM4ME=.530b79e3-d82f-40c3-a553-46ea1a5377f8@github.com>
Message-ID: <DFaC-_rL6ZxQMvLnMQGpY4PLzN3TJ8Qj4dU-RI5tPy0=.8de9a37b-9cdc-42ca-8c72-9a329bbcc7d0@github.com>

On Thu, 17 Mar 2022 11:07:23 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> This PR has been reviewed before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014487.html
> 
> Thanks,
> hedongbo

This looks like a fairly clean backport. The only differences I see are `NoSafepointVerifier` and `No_Safepoint_Verifier` and the lack of the `#ifndef USDT2` block in 8u.

Can you merge this with jdk8u-dev/master so that the GitHub build checks run? Thanks.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/9

From andrew at openjdk.java.net  Sun May 29 16:28:46 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Sun, 29 May 2022 16:28:46 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
Message-ID: <fmZwTf0jL8g7qwl9MCQbcA2Ae4dmj-duKlAG6brsuOI=.4991450a-dfd2-4fe4-ae48-3abbcad821c4@github.com>

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

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

I've opened a PR for the 11u backport: https://github.com/openjdk/jdk11u-dev/pull/1114

Can you merge this with jdk8u-dev/master so that the full set of build checks run?

I've see some whitespace differences with the 8u version:


-+                        (nt = nextTable) == null || transferIndex <= 0)
++                            (nt = nextTable) == null || transferIndex <= 0)



-+                    transferIndex <= 0)
++                        transferIndex <= 0)


Do you see this locally or is it introduced by the `webrev` tool?

The change from `compareAndSetInt` to `compareAndSwapInt` looks correct to match the 8u version.

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

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

From andrew at openjdk.java.net  Sun May 29 16:35:45 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Sun, 29 May 2022 16:35:45 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
Message-ID: <18iU4zouFxRQD20VNgH86-0CnLdxrSRZk8TlYfqVk9A=.722256c4-2105-439f-a47e-076b09f2802b@github.com>

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

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

Name change is solely a renaming; see https://bugs.openjdk.java.net/browse/JDK-8159995 and https://bugs.openjdk.java.net/browse/JDK-8181292

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

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

From andrew at openjdk.java.net  Sun May 29 16:52:49 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Sun, 29 May 2022 16:52:49 GMT
Subject: [jdk8u-dev] RFR: 8235385: Crash on aarch64 JDK due to long offset
 [v3]
In-Reply-To: <ugtAbdBk1MzQLVbJQ5-W4wmMEzcXNvkW8auCAqFx3WI=.b5194acd-287a-4c07-90d9-4e8af586cc35@github.com>
References: <_jge4fRsRjD-AhR_7WvVEr-zQLDFObOrp3W6dC5EDqA=.e9241905-acb7-470f-93a0-12192e9c97f6@github.com>
 <ugtAbdBk1MzQLVbJQ5-W4wmMEzcXNvkW8auCAqFx3WI=.b5194acd-287a-4c07-90d9-4e8af586cc35@github.com>
Message-ID: <ESpte7PRkK2JMiguV0F-WN0-tTe33lcZWpDYVFAzr1o=.a302102a-9c9a-45ee-91ba-ff8f4072c6f3@github.com>

On Mon, 4 Apr 2022 10:58:05 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review backport of 8235385 from jdk11u-dev. Original patch is applied with the following changes (except path shuffling):
>> 
>> - the overload of 'loadStore()' updated to be conform with the baseline
>> - fixed baseline conflicts in copyright sections
>> 
>> Verified (18.04.6 LTS/aarch64) with the reproducers from JBS, 10 of 10 runs passed. Aproximately a half of runs crashed before I've applied the patch.
>> 
>> Regression (18.04.6 LTS/aarch64): compiler & runtime
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing extra empty lines

The testcase is only in this backport. Is there a bug to get this into trunk as well?

Also, please check you have GitHub actions enabled on this repository. It doesn't matter so much for this PR, as there is currently no AArch64 build, but it's important for more general changes.  Thanks.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/30

From dongbohe at openjdk.java.net  Mon May 30 01:22:53 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Mon, 30 May 2022 01:22:53 GMT
Subject: [jdk8u-dev] RFR: 8173361: various crashes in
 JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <XYwkEcOZQzAj1pJk9SBS6SO4GG90ETqkVbZaWlkM4ME=.530b79e3-d82f-40c3-a553-46ea1a5377f8@github.com>
References: <XYwkEcOZQzAj1pJk9SBS6SO4GG90ETqkVbZaWlkM4ME=.530b79e3-d82f-40c3-a553-46ea1a5377f8@github.com>
Message-ID: <ib2jFuTS-mOYP_ZzfpPPLNLboMaeif9cC76LQdma5T4=.8f76dd79-99b9-40a0-8532-9a537f81b8ce@github.com>

> Hi,
> 
> This PR has been reviewed before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014487.html
> 
> Thanks,
> hedongbo

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

 - Merge branch 'master' into 8173361
 - 8173361: various crashes in JvmtiExport::post_compiled_method_load
   
   Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/9/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/9/files/4ce16b1a..dc346d25

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

  Stats: 13179 lines in 186 files changed: 9823 ins; 2087 del; 1269 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/9/head:pull/9

PR: https://git.openjdk.java.net/jdk8u-dev/pull/9

From dongbohe at openjdk.java.net  Mon May 30 01:33:45 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Mon, 30 May 2022 01:33:45 GMT
Subject: [jdk8u-dev] RFR: 8173361: various crashes in
 JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <ib2jFuTS-mOYP_ZzfpPPLNLboMaeif9cC76LQdma5T4=.8f76dd79-99b9-40a0-8532-9a537f81b8ce@github.com>
References: <XYwkEcOZQzAj1pJk9SBS6SO4GG90ETqkVbZaWlkM4ME=.530b79e3-d82f-40c3-a553-46ea1a5377f8@github.com>
 <ib2jFuTS-mOYP_ZzfpPPLNLboMaeif9cC76LQdma5T4=.8f76dd79-99b9-40a0-8532-9a537f81b8ce@github.com>
Message-ID: <YRVvs-YUI6yHYTfgKZptzZXuup2ul36D0Ufz_JPrAqg=.00af7a31-4ac8-4909-8c45-e46e070805d2@github.com>

On Mon, 30 May 2022 01:22:53 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> This PR has been reviewed before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014487.html
>> 
>> Thanks,
>> hedongbo
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8173361
>  - 8173361: various crashes in JvmtiExport::post_compiled_method_load
>    
>    Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241

Thanks for picking this up, I also reopened #19 .

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/9

From dongbohe at openjdk.java.net  Mon May 30 01:36:51 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Mon, 30 May 2022 01:36:51 GMT
Subject: [jdk8u-dev] RFR: 8235218: Minimal VM is broken after JDK-8173361
 [v2]
In-Reply-To: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
Message-ID: <j_AxGhcYEsf2Lg1fC44xMONuYkrsRNNNE1lIRfCuWwY=.dcd8ecd1-9f53-4092-951c-bcb92791db08@github.com>

> Hi,
> 
> I would like to backport this as follow up of [JDK-8173361](https://bugs.openjdk.java.net/browse/JDK-8173361), only a different context.
> 
> Thanks,
> hedongbo

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

 - Merge branch 'master' into 8235218
 - Backport c10f731b11f314c97660df08c62f3c3d2f718f54
 - 8173361: various crashes in JvmtiExport::post_compiled_method_load
   
   Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/19/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/19/files/149be4cf..c12d8390

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

  Stats: 13179 lines in 186 files changed: 9823 ins; 2087 del; 1269 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/19/head:pull/19

PR: https://git.openjdk.java.net/jdk8u-dev/pull/19

From dongbohe at openjdk.java.net  Mon May 30 03:29:19 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Mon, 30 May 2022 03:29:19 GMT
Subject: [jdk8u-dev] RFR: 8173339: AArch64: Fix minimum stack size computations
Message-ID: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>

Hi,

I would like to backport this patch to fix minimum stack size computations on AArch64.
I updated the value directly on `define_pd_global` because [JDK-8078556](https://bugs.openjdk.java.net/browse/JDK-8078556) is not in 8u.

Testing: Following test case worked correctly after patch.
Before patch:
$ java TLSStackOverflow
[1]    35476 segmentation fault (core dumped) java TLSStackOverflow
After patch:
$ java TLSStackOverflow
got expected stackoverflow, passed

$ keytool -genkey -keyalg RSA -keystore localhost-rsa.jks -storepass changeit -storetype pkcs12
$ cat TLSStackOverflow.java

import javax.net.ServerSocketFactory;
import javax.net.SocketFactory;
import javax.net.ssl.*;
import java.io.*;
import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.net.Socket;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.SecureRandom;
import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;

public class TLSStackOverflow
{

    private static final String keystore = "/home/hedongbo/myprojects/study/stackoverflow/new/localhost-rsa.jks";
    private static final char[] passphrase = "changeit".toCharArray();
    private static final int port = 8447;

    private static KeyStore pfx = null;

    public static void doWrite(OutputStream out) throws Exception {
        out.write("hello".getBytes(), 0, 3);
        out.flush();
        doWrite(out);
    }

    public TLSStackOverflow()
    {}

    public static void main(String[] args) throws Exception
    {
        new Thread(() -> {
            try {
                pfx = KeyStore.getInstance("PKCS12");
                pfx.load(new FileInputStream(keystore), passphrase);
                SSLContext ctx = SSLContext.getInstance("TLS");
                KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
                kmf.init(pfx, passphrase);
                KeyManager[] kms = kmf.getKeyManagers();
                ctx.init(kms, null, null);
                ServerSocketFactory fact = ctx.getServerSocketFactory();
                SSLServerSocket serversocket = (SSLServerSocket) fact.createServerSocket(port);
                while (true)
                {
                    Socket socket = null;
                    try
                    {
                        socket = serversocket.accept();

                        DataInputStream in = new DataInputStream(socket.getInputStream());
                        DataOutputStream out = new DataOutputStream(socket.getOutputStream());

                        byte[] buf = new byte[8192];
                        int len = in.read(buf);
                    }
                    catch (Exception e)
                    {
                        e.printStackTrace();
                    }
                    finally
                    {
//                        try
//                        {
//                            socket.close();
//                        }
//                        catch (Exception e) {
//                            e.printStackTrace();
//                        }
                    }
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
        }).start();

        Thread.sleep(2000);

        new Thread(() -> {
            SSLSocket socket = null;
            try {
                pfx = KeyStore.getInstance("PKCS12");
                pfx.load(new FileInputStream(keystore), passphrase);
                SSLContext ctx = SSLContext.getInstance("TLS");
                KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
                kmf.init(pfx, passphrase);
                TrustAllManager[] trust = { new TrustAllManager() };
                ctx.init(null, trust, null);
                SocketFactory fact = ctx.getSocketFactory();
                socket = (SSLSocket) fact.createSocket();
                socket.connect(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 2000);
                socket.setTcpNoDelay(true);
                socket.startHandshake();

                DataInputStream in = new DataInputStream(socket.getInputStream());
                DataOutputStream out = new DataOutputStream(socket.getOutputStream());

                String s = "GET " + " HTTP/1.1\r\n";
                s+= "Accept: */*\r\n";
                s+= "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)\r\n";
                s+= "Connection: Close\r\n";
                s+= "\r\n";
                try {
                    doWrite(out);
                } catch (StackOverflowError e) {
                    System.out.println("got expected stackoverflow, passed");
                    System.exit(0);
                }

                byte[] buf = new byte[8192];
                int len = in.read(buf);
                if (len == -1)
                {
                    System.out.println("eof");
                    return;
                }
                System.out.println(new String(buf, 0, len));
            }
            catch (Exception e)
            {
                e.printStackTrace();
            }
            finally
            {
                try
                {
                    socket.close();
                }
                catch (Exception e)
                {}
            }

        }).start();

    }

}


class TrustAllManager implements X509TrustManager
{
    private X509Certificate[] issuers;

    public TrustAllManager()
    {
        this.issuers = new X509Certificate[0];
    }

    public X509Certificate[] getAcceptedIssuers()
    {
        return issuers ;
    }

    public void checkClientTrusted(X509Certificate[] chain, String authType)
    {}

    public void checkServerTrusted(X509Certificate[] chain, String authType)
    {}
}

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

Commit messages:
 - Backport 540ec375c30e973ceb1a944d5cc60cc8532e88ec

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/66

From duke at openjdk.java.net  Mon May 30 05:38:39 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Mon, 30 May 2022 05:38:39 GMT
Subject: [jdk8u-dev] RFR: 8130895: Test
 javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
In-Reply-To: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
References: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
Message-ID: <y7tMhn1zh5vMLhWBgecUNEm9gZQ9qeWk4oqlJNlL5V8=.81bc3691-5ce8-404f-8f06-005549d7bae2@github.com>

On Wed, 11 May 2022 06:37:29 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> I would like to backport
> JDK-8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
> The original patch applies cleanly after paths changes.
> 
> Testing:
> build on Solaris11.4 sparcv9
> tire1, jdk_awt and javax/swing/system/6799345/TestShutdown.java on Solaris11.4 sparcv9

Could someone please review this backport?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/57

From duke at openjdk.java.net  Mon May 30 06:12:41 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Mon, 30 May 2022 06:12:41 GMT
Subject: [jdk8u-dev] RFR: 8235385: Crash on aarch64 JDK due to long offset
 [v3]
In-Reply-To: <ESpte7PRkK2JMiguV0F-WN0-tTe33lcZWpDYVFAzr1o=.a302102a-9c9a-45ee-91ba-ff8f4072c6f3@github.com>
References: <_jge4fRsRjD-AhR_7WvVEr-zQLDFObOrp3W6dC5EDqA=.e9241905-acb7-470f-93a0-12192e9c97f6@github.com>
 <ugtAbdBk1MzQLVbJQ5-W4wmMEzcXNvkW8auCAqFx3WI=.b5194acd-287a-4c07-90d9-4e8af586cc35@github.com>
 <ESpte7PRkK2JMiguV0F-WN0-tTe33lcZWpDYVFAzr1o=.a302102a-9c9a-45ee-91ba-ff8f4072c6f3@github.com>
Message-ID: <z0yk-wwQV8AAQMMMZV-BbKVsMehneGZeujEtf2uBv7w=.3f8bcb4c-5344-4728-9187-699e3d02b5dc@github.com>

On Sun, 29 May 2022 16:49:35 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> The testcase is only in this backport. Is there a bug to get this into trunk as well?
> 
> Also, please check you have GitHub actions enabled on this repository. It doesn't matter so much for this PR, as there is currently no AArch64 build, but it's important for more general changes. Thanks.

[JDK-8287508](https://bugs.openjdk.java.net/browse/JDK-8287508) raised to port the tests to 11, 15 that incorporates full version of the patch includes the tests

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/30

From duke at openjdk.java.net  Mon May 30 06:57:44 2022
From: duke at openjdk.java.net (Long Yang)
Date: Mon, 30 May 2022 06:57:44 GMT
Subject: [jdk8u-dev] RFR: 8260589: Crash in
 JfrTraceIdLoadBarrier::load(_jclass*) [v2]
In-Reply-To: <s3gnxE6q7VA8DMcUl6HeLBjf0La8dw6-a9mkE45tC18=.ec1f7e5b-eb11-4dc0-b593-019baa76ea28@github.com>
References: <s3gnxE6q7VA8DMcUl6HeLBjf0La8dw6-a9mkE45tC18=.ec1f7e5b-eb11-4dc0-b593-019baa76ea28@github.com>
Message-ID: <RqDZKhlEB113ywS-K3fF_hhPLqTrAqqSJY9pLttYGvk=.bc239350-109b-4c0a-8f83-4ded80a03dbf@github.com>

> Hi!
> 
> Please review the backport of JDK-8260589 to 8u.
> This crash problem is easy to reproduce, so I feel it is necessary to backport it to 8u.
> 
> 3 months ago, I launched webrev and it has been reviewed by Zhengyu Gu ([the review mail link](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-March/014715.html)), thanks a lot to Zhengyu and Mario.
> Recently, I learned that the review method of 8u was changed to github, so I re-launched it in the new way.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8260589
> 11u commit: https://github.com/openjdk/jdk11u-dev/commit/1d204c554ffe969567161cc05992486ff47d346d
> Test: jdk/test/jdk/jfr/jvm/TestPrimitiveClasses.java passed.
> 
> Due to the differences between JFR in 11u and 17, Denghui made some changes when backporting this fix to 11u. 
> Denghui's changes also apply to 8u, so I directly quote Denghui's list here. (4 in total)
> 1. use MaxJfrEventId + 101 instead of LAST_TYPE_ID + 1 as the klass id of void.class
> 2. jdk 11 doesn't support jfr streaming, so I removed the call `JfrTraceIdEpoch::set_changed_tag_state()` in `load_primitive`
> 3. the Class in jdk 11 doesn't have the field 'hidden', so I removed `writer->write<bool>(false);` in `write_primitive`
> 4. there are many differences in the API of JfrTraceId between 11u and tip
> 
> In addition to the above differences, I also make supplementary explanations for the modifications I made.
> 1. The static global variable clear_artifacts in 11u was introduced by the bugfix https://bugs.openjdk.java.net/browse/JDK-8231081, but this fix has not been backported to 8u, so I removed the code related to clear_artifacts. In 8u, the metadata of the primitive types will be written into the previous chunk on every chunk rotation.
> 2. In 11u, _artifacts and _class_unload are static global variables, but in 8u, they are static member variables of JfrTypeSet, so I also made necessary changes to the functions that use these two variables.
> 
> Thanks

Long Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Backport a9d2267f8d306522522c999ff584ccaa34c46456
  Reviewed-by: Zhengyu Gu
  Backport-of: a9d2267f8d306522522c999ff584ccaa34c46456

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/36/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/36/files/1ca0c4a5..8a41ed27

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

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/36

From aph at openjdk.java.net  Mon May 30 08:25:28 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 30 May 2022 08:25:28 GMT
Subject: [jdk8u-dev] RFR: 8173339: AArch64: Fix minimum stack size
 computations
In-Reply-To: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
References: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
Message-ID: <o0jqbEDi6W3NwL-75lNeGXSTkPGmZpsbsRAw0BMeWXU=.3d5b8cfe-c495-4b3f-ae5c-042e0fa9bc0a@github.com>

On Mon, 30 May 2022 03:22:04 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this patch to fix minimum stack size computations on AArch64.
> I updated the value directly on `define_pd_global` because [JDK-8078556](https://bugs.openjdk.java.net/browse/JDK-8078556) is not in 8u.
> 
> Testing: Following test case worked correctly after patch.
> Before patch:
> $ java TLSStackOverflow
> [1]    35476 segmentation fault (core dumped) java TLSStackOverflow
> After patch:
> $ java TLSStackOverflow
> got expected stackoverflow, passed
> 
> $ keytool -genkey -keyalg RSA -keystore localhost-rsa.jks -storepass changeit -storetype pkcs12
> $ cat TLSStackOverflow.java
> 
> import javax.net.ServerSocketFactory;
> import javax.net.SocketFactory;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.net.Socket;
> import java.security.KeyStore;
> import java.security.KeyStoreException;
> import java.security.NoSuchAlgorithmException;
> import java.security.SecureRandom;
> import java.security.cert.CertificateException;
> import java.security.cert.X509Certificate;
> 
> public class TLSStackOverflow
> {
> 
>     private static final String keystore = "/home/hedongbo/myprojects/study/stackoverflow/new/localhost-rsa.jks";
>     private static final char[] passphrase = "changeit".toCharArray();
>     private static final int port = 8447;
> 
>     private static KeyStore pfx = null;
> 
>     public static void doWrite(OutputStream out) throws Exception {
>         out.write("hello".getBytes(), 0, 3);
>         out.flush();
>         doWrite(out);
>     }
> 
>     public TLSStackOverflow()
>     {}
> 
>     public static void main(String[] args) throws Exception
>     {
>         new Thread(() -> {
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 KeyManager[] kms = kmf.getKeyManagers();
>                 ctx.init(kms, null, null);
>                 ServerSocketFactory fact = ctx.getServerSocketFactory();
>                 SSLServerSocket serversocket = (SSLServerSocket) fact.createServerSocket(port);
>                 while (true)
>                 {
>                     Socket socket = null;
>                     try
>                     {
>                         socket = serversocket.accept();
> 
>                         DataInputStream in = new DataInputStream(socket.getInputStream());
>                         DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                         byte[] buf = new byte[8192];
>                         int len = in.read(buf);
>                     }
>                     catch (Exception e)
>                     {
>                         e.printStackTrace();
>                     }
>                     finally
>                     {
> //                        try
> //                        {
> //                            socket.close();
> //                        }
> //                        catch (Exception e) {
> //                            e.printStackTrace();
> //                        }
>                     }
>                 }
>             } catch (Exception e) {
>                 e.printStackTrace();
>             }
>         }).start();
> 
>         Thread.sleep(2000);
> 
>         new Thread(() -> {
>             SSLSocket socket = null;
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 TrustAllManager[] trust = { new TrustAllManager() };
>                 ctx.init(null, trust, null);
>                 SocketFactory fact = ctx.getSocketFactory();
>                 socket = (SSLSocket) fact.createSocket();
>                 socket.connect(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 2000);
>                 socket.setTcpNoDelay(true);
>                 socket.startHandshake();
> 
>                 DataInputStream in = new DataInputStream(socket.getInputStream());
>                 DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                 String s = "GET " + " HTTP/1.1\r\n";
>                 s+= "Accept: */*\r\n";
>                 s+= "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)\r\n";
>                 s+= "Connection: Close\r\n";
>                 s+= "\r\n";
>                 try {
>                     doWrite(out);
>                 } catch (StackOverflowError e) {
>                     System.out.println("got expected stackoverflow, passed");
>                     System.exit(0);
>                 }
> 
>                 byte[] buf = new byte[8192];
>                 int len = in.read(buf);
>                 if (len == -1)
>                 {
>                     System.out.println("eof");
>                     return;
>                 }
>                 System.out.println(new String(buf, 0, len));
>             }
>             catch (Exception e)
>             {
>                 e.printStackTrace();
>             }
>             finally
>             {
>                 try
>                 {
>                     socket.close();
>                 }
>                 catch (Exception e)
>                 {}
>             }
> 
>         }).start();
> 
>     }
> 
> }
> 
> 
> class TrustAllManager implements X509TrustManager
> {
>     private X509Certificate[] issuers;
> 
>     public TrustAllManager()
>     {
>         this.issuers = new X509Certificate[0];
>     }
> 
>     public X509Certificate[] getAcceptedIssuers()
>     {
>         return issuers ;
>     }
> 
>     public void checkClientTrusted(X509Certificate[] chain, String authType)
>     {}
> 
>     public void checkServerTrusted(X509Certificate[] chain, String authType)
>     {}
> }

Looks fine. I was a bit freaked out because I'd forgotten that this is a count of "theoretical" 4k pages, regardless of the actual page size, which is 64k on some AArch64 systems.

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

Marked as reviewed by aph (Lead).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/66

From yan at openjdk.java.net  Mon May 30 12:19:23 2022
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Mon, 30 May 2022 12:19:23 GMT
Subject: [jdk8u-dev] RFR: 8087283: Add support for the XML Signature here()
 function to the JDK XPath implementation
Message-ID: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>

I'd like to backport this jdk9 change to jdk8 because it would make backporting future important fixes and related tests easier. It is marked as Enhancement, however with time the absence of it would become nuisance. 
I've tested it so far with various XML-related tests. Tier tests are running.

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

Commit messages:
 - Backport 22fad64529a890dd3ae8b07c7981d9a720cf8e96

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/67/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=67&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8087283
  Stats: 135 lines in 3 files changed: 120 ins; 1 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/67.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/67/head:pull/67

PR: https://git.openjdk.java.net/jdk8u-dev/pull/67

From gnu.andrew at redhat.com  Mon May 30 13:07:38 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 30 May 2022 14:07:38 +0100
Subject: [RAMPDOWN] 8u342 now in Rampdown Stage
Message-ID: <YpTBminGmhN+N5hB@hex>

8u342 is now in rampdown for release in July.

jdk8u-dev is CLOSED for commits until
https://bugs.openjdk.java.net/browse/JDK-8287521 is integrated to
begin the 8u352 release cycle.

For critical fixes (i.e. regressions or urgent fixes) for 8u342,
please file a PR against https://github.com/openjdk/jdk8u and use
jdk8u-critical-request to obtain approval to push.

Note that I'm currently seeing build failures of 8u342-b04 on
AArch64:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000ffffbd337390, pid=4091, tid=0x0000ffffac36f200
#
# JRE version: OpenJDK Runtime Environment (8.0_342-b04) (build 1.8.0_342-ea-debug-b04)
# Java VM: OpenJDK 64-Bit Server VM (25.342-b04-debug mixed mode linux-aarch64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x327390]  Chunk::next() const+0xc

I'll file a bug when I have more information, but I suspect this may
be JDK-8284620: CodeBuffer may leak _overflow_arena which is the only
HotSpot change in that build promotion. This does seem to have made
its way to 8u quite quickly.

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

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

From andrew at openjdk.java.net  Mon May 30 13:22:41 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 30 May 2022 13:22:41 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows
In-Reply-To: <HZb4Pq-X_z8ZPsjPTVAQSArVxOg0Deh9e-0B9npJVUA=.49744634-9bc2-4225-bff6-b0d2295962b0@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
 <HZb4Pq-X_z8ZPsjPTVAQSArVxOg0Deh9e-0B9npJVUA=.49744634-9bc2-4225-bff6-b0d2295962b0@github.com>
Message-ID: <REPWHKtOksRHLqMeO30DbETDodNEQorhg6SSvI91jyY=.7ef33d5a-27f1-4737-aa0f-e57a4f41b000@github.com>

On Fri, 13 May 2022 17:15:42 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> Would it be better if I add a `PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC` change as a separate backport?
> 
> I understand that it is a part of the same original change, just the motivation behind the change is completely different from the format strings change that are included now. I am fine with doing it either way, just wanted to point out that the inclusion of pragma here may be confusing.

Yes, that makes sense. We're already deviating from the original enhancement issue with this subset to fix a bug. Please file a bug and I'll approve this once the repository has transitioned to 8u352.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/45

From dongbohe at openjdk.java.net  Mon May 30 13:40:47 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Mon, 30 May 2022 13:40:47 GMT
Subject: [jdk8u-dev] RFR: 8173339: AArch64: Fix minimum stack size
 computations
In-Reply-To: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
References: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
Message-ID: <SIZnh6w2mwnZwnHgWY8L4md5xKyLoQJMuxcmC0hD7W0=.edabba74-c68e-45e0-bc51-ff7825f92fcb@github.com>

On Mon, 30 May 2022 03:22:04 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this patch to fix minimum stack size computations on AArch64.
> I updated the value directly on `define_pd_global` because [JDK-8078556](https://bugs.openjdk.java.net/browse/JDK-8078556) is not in 8u.
> 
> Testing: Following test case worked correctly after patch.
> Before patch:
> $ java TLSStackOverflow
> [1]    35476 segmentation fault (core dumped) java TLSStackOverflow
> After patch:
> $ java TLSStackOverflow
> got expected stackoverflow, passed
> 
> $ keytool -genkey -keyalg RSA -keystore localhost-rsa.jks -storepass changeit -storetype pkcs12
> $ cat TLSStackOverflow.java
> 
> import javax.net.ServerSocketFactory;
> import javax.net.SocketFactory;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.net.Socket;
> import java.security.KeyStore;
> import java.security.KeyStoreException;
> import java.security.NoSuchAlgorithmException;
> import java.security.SecureRandom;
> import java.security.cert.CertificateException;
> import java.security.cert.X509Certificate;
> 
> public class TLSStackOverflow
> {
> 
>     private static final String keystore = "/home/hedongbo/myprojects/study/stackoverflow/new/localhost-rsa.jks";
>     private static final char[] passphrase = "changeit".toCharArray();
>     private static final int port = 8447;
> 
>     private static KeyStore pfx = null;
> 
>     public static void doWrite(OutputStream out) throws Exception {
>         out.write("hello".getBytes(), 0, 3);
>         out.flush();
>         doWrite(out);
>     }
> 
>     public TLSStackOverflow()
>     {}
> 
>     public static void main(String[] args) throws Exception
>     {
>         new Thread(() -> {
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 KeyManager[] kms = kmf.getKeyManagers();
>                 ctx.init(kms, null, null);
>                 ServerSocketFactory fact = ctx.getServerSocketFactory();
>                 SSLServerSocket serversocket = (SSLServerSocket) fact.createServerSocket(port);
>                 while (true)
>                 {
>                     Socket socket = null;
>                     try
>                     {
>                         socket = serversocket.accept();
> 
>                         DataInputStream in = new DataInputStream(socket.getInputStream());
>                         DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                         byte[] buf = new byte[8192];
>                         int len = in.read(buf);
>                     }
>                     catch (Exception e)
>                     {
>                         e.printStackTrace();
>                     }
>                     finally
>                     {
> //                        try
> //                        {
> //                            socket.close();
> //                        }
> //                        catch (Exception e) {
> //                            e.printStackTrace();
> //                        }
>                     }
>                 }
>             } catch (Exception e) {
>                 e.printStackTrace();
>             }
>         }).start();
> 
>         Thread.sleep(2000);
> 
>         new Thread(() -> {
>             SSLSocket socket = null;
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 TrustAllManager[] trust = { new TrustAllManager() };
>                 ctx.init(null, trust, null);
>                 SocketFactory fact = ctx.getSocketFactory();
>                 socket = (SSLSocket) fact.createSocket();
>                 socket.connect(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 2000);
>                 socket.setTcpNoDelay(true);
>                 socket.startHandshake();
> 
>                 DataInputStream in = new DataInputStream(socket.getInputStream());
>                 DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                 String s = "GET " + " HTTP/1.1\r\n";
>                 s+= "Accept: */*\r\n";
>                 s+= "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)\r\n";
>                 s+= "Connection: Close\r\n";
>                 s+= "\r\n";
>                 try {
>                     doWrite(out);
>                 } catch (StackOverflowError e) {
>                     System.out.println("got expected stackoverflow, passed");
>                     System.exit(0);
>                 }
> 
>                 byte[] buf = new byte[8192];
>                 int len = in.read(buf);
>                 if (len == -1)
>                 {
>                     System.out.println("eof");
>                     return;
>                 }
>                 System.out.println(new String(buf, 0, len));
>             }
>             catch (Exception e)
>             {
>                 e.printStackTrace();
>             }
>             finally
>             {
>                 try
>                 {
>                     socket.close();
>                 }
>                 catch (Exception e)
>                 {}
>             }
> 
>         }).start();
> 
>     }
> 
> }
> 
> 
> class TrustAllManager implements X509TrustManager
> {
>     private X509Certificate[] issuers;
> 
>     public TrustAllManager()
>     {
>         this.issuers = new X509Certificate[0];
>     }
> 
>     public X509Certificate[] getAcceptedIssuers()
>     {
>         return issuers ;
>     }
> 
>     public void checkClientTrusted(X509Certificate[] chain, String authType)
>     {}
> 
>     public void checkServerTrusted(X509Certificate[] chain, String authType)
>     {}
> }

Thank you for your review, Andrew. Tagged the JBS issue with jdk8u-fix-request.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/66

From andrew at openjdk.java.net  Mon May 30 13:54:15 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 30 May 2022 13:54:15 GMT
Subject: [jdk8u-dev] RFR: 8287521: Bump update version of OpenJDK: 8u352
Message-ID: <iVw0Fv_z-wC0pWDrmwdTQGuGmutPLAxjXQNRzyQ-M64=.3c6947f8-4389-48b7-96cf-36dd0c79d29e@github.com>

Rampdown for 8u342 has begun. 8u-dev needs to transition to 8u352.

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

Commit messages:
 - 8287521: Bump update version of OpenJDK: 8u352

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/68

From sgehwolf at openjdk.java.net  Mon May 30 14:03:48 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 30 May 2022 14:03:48 GMT
Subject: [jdk8u-dev] RFR: 8287521: Bump update version of OpenJDK: 8u352
In-Reply-To: <iVw0Fv_z-wC0pWDrmwdTQGuGmutPLAxjXQNRzyQ-M64=.3c6947f8-4389-48b7-96cf-36dd0c79d29e@github.com>
References: <iVw0Fv_z-wC0pWDrmwdTQGuGmutPLAxjXQNRzyQ-M64=.3c6947f8-4389-48b7-96cf-36dd0c79d29e@github.com>
Message-ID: <VtQNS5xXV9_CANS4a_LSA7qO4bRE1g_xRl1V_1KL2Gc=.e791b4ae-db3b-4668-992c-f5deae60bfee@github.com>

On Mon, 30 May 2022 13:48:12 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Rampdown for 8u342 has begun. 8u-dev needs to transition to 8u352.

LGTM

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/68

From andrew at openjdk.java.net  Mon May 30 14:33:44 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 30 May 2022 14:33:44 GMT
Subject: [jdk8u-dev] RFR: 8287521: Bump update version of OpenJDK: 8u352
In-Reply-To: <iVw0Fv_z-wC0pWDrmwdTQGuGmutPLAxjXQNRzyQ-M64=.3c6947f8-4389-48b7-96cf-36dd0c79d29e@github.com>
References: <iVw0Fv_z-wC0pWDrmwdTQGuGmutPLAxjXQNRzyQ-M64=.3c6947f8-4389-48b7-96cf-36dd0c79d29e@github.com>
Message-ID: <2p2GMRFo7tejmj0_2aGHdVdbIStey0YWN-rIZHkDRgg=.e2118666-0c31-411c-9462-3e4d7d4df0be@github.com>

On Mon, 30 May 2022 13:48:12 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Rampdown for 8u342 has begun. 8u-dev needs to transition to 8u352.

Thanks. Bug flagged with `jdk8u-fix-request` (not sure if we need this step for this kind of thing, but done it anyway)

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/68

From andrew at openjdk.java.net  Mon May 30 15:16:32 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 30 May 2022 15:16:32 GMT
Subject: [jdk8u-dev] RFR: 8287521: Bump update version of OpenJDK: 8u352
In-Reply-To: <iVw0Fv_z-wC0pWDrmwdTQGuGmutPLAxjXQNRzyQ-M64=.3c6947f8-4389-48b7-96cf-36dd0c79d29e@github.com>
References: <iVw0Fv_z-wC0pWDrmwdTQGuGmutPLAxjXQNRzyQ-M64=.3c6947f8-4389-48b7-96cf-36dd0c79d29e@github.com>
Message-ID: <cbi9ENTurAKKsMjHttWXzlKc2OfUSO2dQTCh1y-80u0=.f0e19f8a-ba31-4695-943c-49f855ae6ec1@github.com>

On Mon, 30 May 2022 13:48:12 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Rampdown for 8u342 has begun. 8u-dev needs to transition to 8u352.

I see `jdk8u-fix-yes`

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/68

From andrew at openjdk.java.net  Mon May 30 15:16:32 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 30 May 2022 15:16:32 GMT
Subject: [jdk8u-dev] Integrated: 8287521: Bump update version of OpenJDK: 8u352
In-Reply-To: <iVw0Fv_z-wC0pWDrmwdTQGuGmutPLAxjXQNRzyQ-M64=.3c6947f8-4389-48b7-96cf-36dd0c79d29e@github.com>
References: <iVw0Fv_z-wC0pWDrmwdTQGuGmutPLAxjXQNRzyQ-M64=.3c6947f8-4389-48b7-96cf-36dd0c79d29e@github.com>
Message-ID: <S2-DxrRT__m2r1DJ_HNd9ML97XtXlmOYM6dLvikVCAM=.04dddf33-8277-4cb7-8b49-22d91b9e9fed@github.com>

On Mon, 30 May 2022 13:48:12 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Rampdown for 8u342 has begun. 8u-dev needs to transition to 8u352.

This pull request has now been integrated.

Changeset: f3c87ce7
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/f3c87ce70bcc8421ec40e393e9649dfac30d2336
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8287521: Bump update version of OpenJDK: 8u352

Reviewed-by: sgehwolf

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/68

From andrew at openjdk.java.net  Mon May 30 15:35:47 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 30 May 2022 15:35:47 GMT
Subject: [jdk8u-dev] RFR: 8235385: Crash on aarch64 JDK due to long offset
 [v3]
In-Reply-To: <ugtAbdBk1MzQLVbJQ5-W4wmMEzcXNvkW8auCAqFx3WI=.b5194acd-287a-4c07-90d9-4e8af586cc35@github.com>
References: <_jge4fRsRjD-AhR_7WvVEr-zQLDFObOrp3W6dC5EDqA=.e9241905-acb7-470f-93a0-12192e9c97f6@github.com>
 <ugtAbdBk1MzQLVbJQ5-W4wmMEzcXNvkW8auCAqFx3WI=.b5194acd-287a-4c07-90d9-4e8af586cc35@github.com>
Message-ID: <OFdYvRGMGCq3STTZnbE8JwLW193Bcds7zQfE98K5KTE=.971b846f-588b-4590-a727-984c669cb419@github.com>

On Mon, 4 Apr 2022 10:58:05 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review backport of 8235385 from jdk11u-dev. Original patch is applied with the following changes (except path shuffling):
>> 
>> - the overload of 'loadStore()' updated to be conform with the baseline
>> - fixed baseline conflicts in copyright sections
>> 
>> Verified (18.04.6 LTS/aarch64) with the reproducers from JBS, 10 of 10 runs passed. Aproximately a half of runs crashed before I've applied the patch.
>> 
>> Regression (18.04.6 LTS/aarch64): compiler & runtime
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing extra empty lines

Thanks for filing the bug. I've removed the linked backport issues as they were for the original fix, not the test, and it wrongly makes it look like it is already fixed in 11u. When the test is backported, SKARA will automatically create backport bugs and link them.

If you use the issue command above, you should be able to reference the bug in this PR too.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/30

From andrew at openjdk.java.net  Mon May 30 15:45:55 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 30 May 2022 15:45:55 GMT
Subject: [jdk8u-dev] RFR: 8173361: various crashes in
 JvmtiExport::post_compiled_method_load [v2]
In-Reply-To: <ib2jFuTS-mOYP_ZzfpPPLNLboMaeif9cC76LQdma5T4=.8f76dd79-99b9-40a0-8532-9a537f81b8ce@github.com>
References: <XYwkEcOZQzAj1pJk9SBS6SO4GG90ETqkVbZaWlkM4ME=.530b79e3-d82f-40c3-a553-46ea1a5377f8@github.com>
 <ib2jFuTS-mOYP_ZzfpPPLNLboMaeif9cC76LQdma5T4=.8f76dd79-99b9-40a0-8532-9a537f81b8ce@github.com>
Message-ID: <R6WwYcc89aVrrfqcqYz9siG8hF3J2k8lxVRhJDtV7tw=.bb2998a6-ec4a-48e6-9135-46b77988d9d8@github.com>

On Mon, 30 May 2022 01:22:53 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> This PR has been reviewed before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014487.html
>> 
>> Thanks,
>> hedongbo
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8173361
>  - 8173361: various crashes in JvmtiExport::post_compiled_method_load
>    
>    Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241

Build runs look good.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/9

From alitvinov at openjdk.java.net  Mon May 30 15:55:48 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Mon, 30 May 2022 15:55:48 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v4]
In-Reply-To: <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
 <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>
Message-ID: <pbsohWXN1j1ynCpQIFI51G5_9MIrqvVVQ8ViLniYcbo=.48940a2a-516c-444d-8375-bb109e4e1e1b@github.com>

On Sat, 28 May 2022 00:22:03 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
>> The original patch for JDK-8194873 applied not cleanly due to 2 files:   
>>>  MotifLookAndFeel.java - differences in the header and in the context;
>>>  SwingUtilities2.java - difference in the context.
>> 
>> The backport for JDK-8155742
>> 
>> 8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows
>> 
>> was included as a part of this patch due to dependency on it of the regression test "jdk/test/javax/swing/event/RightAltKeyTest.java" included into the patch for JDK-8194873 (this test fails without the patch for JDK-8155742 as was pointed out below by Anton Litvinov).
>> The original patch For JDK-8155742 applied not cleanly due to 1 file:
>>> AltGraphModifierTest.java - differences in the header and slight in the context.
>> 
>> Tested on Windows. All regular tests passed.
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backport 08482543b496efa11dc8084a14a831799de60a93

Hi Olga. The version "03" of the fix looks good.

Thank you,
Anton

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

Marked as reviewed by alitvinov (Committer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From alitvinov at openjdk.java.net  Mon May 30 16:10:48 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Mon, 30 May 2022 16:10:48 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v4]
In-Reply-To: <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
 <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>
Message-ID: <SFxCcP48bfKWC5e1iJ9EvH0akAer5BmGykcR5Q1PNRs=.3c6e11e2-19a4-48d6-9308-60802ec75f43@github.com>

On Sat, 28 May 2022 00:22:03 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
>> The original patch for JDK-8194873 applied not cleanly due to 2 files:   
>>>  MotifLookAndFeel.java - differences in the header and in the context;
>>>  SwingUtilities2.java - difference in the context.
>> 
>> The backport for JDK-8155742
>> 
>> 8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows
>> 
>> was included as a part of this patch due to dependency on it of the regression test "jdk/test/javax/swing/event/RightAltKeyTest.java" included into the patch for JDK-8194873 (this test fails without the patch for JDK-8155742 as was pointed out below by Anton Litvinov).
>> The original patch For JDK-8155742 applied not cleanly due to 1 file:
>>> AltGraphModifierTest.java - differences in the header and slight in the context.
>> 
>> Tested on Windows. All regular tests passed.
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backport 08482543b496efa11dc8084a14a831799de60a93

Hi Olga. It seems that my reviewer status in JDK Project does not have effect in this "jdk8u-dev" repository. So most probably you will have to find a person with the reviewer status in this particular repository and to ask him to review and approve this backport fix, otherwise the bot will not let you enter "/integrate" command.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From andrew at openjdk.java.net  Mon May 30 16:31:18 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 30 May 2022 16:31:18 GMT
Subject: [jdk8u] RFR: 8285591: [11] add signum checks in DSA.java engineVerify
Message-ID: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>

This change was part of a security fix, JDK-8277233, for 17u during the April update.  The rest of 8277233 did not apply to older releases, as it concerned code added to ` src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java` by JDK-8237218 in 15u.

However, the additional checks in `src/java.base/share/classes/sun/security/provider/DSA.java` that were included in the patch are applicable to older releases.

I'm raising this for inclusion in 8u342 during rampdown as 17u already has it since the April update and 11u now has this backport. It would be good for 8u to be consistent as soon as possible.

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

Commit messages:
 - Backport bf3438c5dc993b96d089cabb5318bfc64a6904a3

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

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

From andrew at openjdk.java.net  Mon May 30 16:31:18 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Mon, 30 May 2022 16:31:18 GMT
Subject: [jdk8u] RFR: 8285591: [11] add signum checks in DSA.java
 engineVerify
In-Reply-To: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
References: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
Message-ID: <QiTG-HeELwA4stDBUvH-h4vRNIifEeErHjONZ5Wxx3g=.a63c4c4e-42a8-436c-9742-be957b085328@github.com>

On Mon, 30 May 2022 16:22:14 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This change was part of a security fix, JDK-8277233, for 17u during the April update.  The rest of 8277233 did not apply to older releases, as it concerned code added to ` src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java` by JDK-8237218 in 15u.
> 
> However, the additional checks in `src/java.base/share/classes/sun/security/provider/DSA.java` that were included in the patch are applicable to older releases.
> 
> I'm raising this for inclusion in 8u342 during rampdown as 17u already has it since the April update and 11u now has this backport. It would be good for 8u to be consistent as soon as possible.

Code change itself applied cleanly. Only the copyright header had to be manually applied, as 8u lacks JDK-8146293

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

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

From omikhaltcova at openjdk.java.net  Mon May 30 16:31:54 2022
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Mon, 30 May 2022 16:31:54 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v4]
In-Reply-To: <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
 <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>
Message-ID: <XS5TnlbSO6sE_NHaKOlUikJYF9HaPXQJQHgt3EXkqw0=.fd4827ca-0416-421b-930c-d2014ab963d9@github.com>

On Sat, 28 May 2022 00:22:03 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
>> The original patch for JDK-8194873 applied not cleanly due to 2 files:   
>>>  MotifLookAndFeel.java - differences in the header and in the context;
>>>  SwingUtilities2.java - difference in the context.
>> 
>> The backport for JDK-8155742
>> 
>> 8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows
>> 
>> was included as a part of this patch due to dependency on it of the regression test "jdk/test/javax/swing/event/RightAltKeyTest.java" included into the patch for JDK-8194873 (this test fails without the patch for JDK-8155742 as was pointed out below by Anton Litvinov).
>> The original patch For JDK-8155742 applied not cleanly due to 1 file:
>>> AltGraphModifierTest.java - differences in the header and slight in the context.
>> 
>> Tested on Windows. All regular tests passed.
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backport 08482543b496efa11dc8084a14a831799de60a93

Thanks, Anton, for helping me!
At the moment I'm thinking of reworking this PR into 2 separate PRs. One of them will be a dependant PR due to the test failure. How do you think it's worth doing?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From alitvinov at openjdk.java.net  Mon May 30 17:27:45 2022
From: alitvinov at openjdk.java.net (Anton Litvinov)
Date: Mon, 30 May 2022 17:27:45 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v4]
In-Reply-To: <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
 <fAWh1qC3971UGzrXjFWDSaQlsAgE5BEkmkJBryI-gA0=.373e468d-f499-4378-b2f0-23d75ee26f5f@github.com>
Message-ID: <ozMgpbaaxfxEV6IE87lZNXhhKzIPk-ppICezXMTzWrg=.dfdfb852-4bdf-4e36-805b-1896f932f4c5@github.com>

On Sat, 28 May 2022 00:22:03 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
>> The original patch for JDK-8194873 applied not cleanly due to 2 files:   
>>>  MotifLookAndFeel.java - differences in the header and in the context;
>>>  SwingUtilities2.java - difference in the context.
>> 
>> The backport for JDK-8155742
>> 
>> 8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows
>> 
>> was included as a part of this patch due to dependency on it of the regression test "jdk/test/javax/swing/event/RightAltKeyTest.java" included into the patch for JDK-8194873 (this test fails without the patch for JDK-8155742 as was pointed out below by Anton Litvinov).
>> The original patch For JDK-8155742 applied not cleanly due to 1 file:
>>> AltGraphModifierTest.java - differences in the header and slight in the context.
>> 
>> Tested on Windows. All regular tests passed.
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backport 08482543b496efa11dc8084a14a831799de60a93

No problem. If backports of the involved 2 bugs were clean, then it would make sense to accomplish them through 2 separate PRs in order to not involve anybody in their review, but in your case your backport has insignificant differences between it and the original fixes, as you wrote "difference in the context", therefore it will be required to get approval from the code reviewer for each of these possible PRs. Regarding the current PR, from my point of view it is also correct to combine backports of 2 bugs in one fix, because otherwise the test "RightAltKeyTest.java" will be failing.

Before pushing this change as is or under separate PRs, I would also recommend to look more carefully on 2 regression tests modified by the fix JDK-8155742: "ModifierRobotKeyTest.java", "AltGraphModifierTest.java". Make sure that they pass on the supported OS versions, not only on MS Windows OS. And, if they fail, and you decide to start porting other fixes, which could be connected to "AltGraphModifierTest.java" through the source code and which are specific to macOS and to keyboard events, I do not recommend even to touch these macOS specific fixes, it will be a chain of more than 10 fixes connected with each other as a regression of a fix for regression and in the end there will be couple of regressions still unresolved, so do not port those fixes specific to keyboard events on macOS. I personally did not port them for that reason.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/60

From gnu.andrew at redhat.com  Tue May 31 01:31:24 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 31 May 2022 02:31:24 +0100
Subject: [RAMPDOWN] 8u342 now in Rampdown Stage
In-Reply-To: <YpTBminGmhN+N5hB@hex>
References: <YpTBminGmhN+N5hB@hex>
Message-ID: <YpVv7NrI5zsIrKU6@hex>

On 14:07 Mon 30 May     , Andrew Hughes wrote:
> 8u342 is now in rampdown for release in July.
> 
> jdk8u-dev is CLOSED for commits until
> https://bugs.openjdk.java.net/browse/JDK-8287521 is integrated to
> begin the 8u352 release cycle.
>

This is now integrated, so commits for 8u352 can commence,
after the usual review and approval process.

https://git.openjdk.java.net/jdk8u-dev/commit/f3c87ce70bcc8421ec40e393e9649dfac30d2336

> For critical fixes (i.e. regressions or urgent fixes) for 8u342,
> please file a PR against https://github.com/openjdk/jdk8u and use
> jdk8u-critical-request to obtain approval to push.
> 
> Note that I'm currently seeing build failures of 8u342-b04 on
> AArch64:
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x0000ffffbd337390, pid=4091, tid=0x0000ffffac36f200
> #
> # JRE version: OpenJDK Runtime Environment (8.0_342-b04) (build 1.8.0_342-ea-debug-b04)
> # Java VM: OpenJDK 64-Bit Server VM (25.342-b04-debug mixed mode linux-aarch64 compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x327390]  Chunk::next() const+0xc
> 
> I'll file a bug when I have more information, but I suspect this may
> be JDK-8284620: CodeBuffer may leak _overflow_arena which is the only
> HotSpot change in that build promotion. This does seem to have made
> its way to 8u quite quickly.
>

Backing out JDK-8284620 fixed the issue, so this does seem to be causing a regression
on AArch64. Filed https://bugs.openjdk.java.net/browse/JDK-8287537

I will back this out if it is not otherwise fixed by the time we come to freeze 8u342
in about a month's time.

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

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

From andrew at openjdk.java.net  Tue May 31 01:38:42 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 31 May 2022 01:38:42 GMT
Subject: [jdk8u-dev] RFR: 8284620: CodeBuffer may leak _overflow_arena
In-Reply-To: <0_0B3Wbda4gVbRm3uG08U7LME-LsSx6BR8UCLcc_1R0=.aaa95d24-1947-409d-84a0-2361d507ef7d@github.com>
References: <0_0B3Wbda4gVbRm3uG08U7LME-LsSx6BR8UCLcc_1R0=.aaa95d24-1947-409d-84a0-2361d507ef7d@github.com>
Message-ID: <RPLW0cpPyuNcg0cdUbk6i-UDSjU226wqPatqk6lc_5s=.09d8b257-2fe6-426f-b37e-aa983c6a6c36@github.com>

On Mon, 2 May 2022 12:32:21 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to backport this patch to 8u for fixing a memory leak.
> 
> The original patch does not apply cleanly due to context difference. However, the patch is small, easily resolved manually.
> 
> Test:
> 
> - [x]  hotspot_compiler

This has broken the build on AArch64: https://bugs.openjdk.java.net/browse/JDK-8287537

Not sure if it is related but this change uses `delete _overflow_arena;` while the original has `delete cb->_overflow_arena;`
I'm guessing the AArch64 build is trying to access something it does not expect to be NULL.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/52

From andrew at openjdk.java.net  Tue May 31 01:53:45 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 31 May 2022 01:53:45 GMT
Subject: [jdk8u] RFR: 8285591: [11] add signum checks in DSA.java
 engineVerify
In-Reply-To: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
References: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
Message-ID: <yip1bgBFN81S5ST1dO6aqPaCNlThwwXEYVTJLq9lmAc=.fc047a72-1931-46aa-91ea-9730082c15f7@github.com>

On Mon, 30 May 2022 16:22:14 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This change was part of a security fix, JDK-8277233, for 17u during the April update.  The rest of 8277233 did not apply to older releases, as it concerned code added to ` src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java` by JDK-8237218 in 15u.
> 
> However, the additional checks in `src/java.base/share/classes/sun/security/provider/DSA.java` that were included in the patch are applicable to older releases.
> 
> I'm raising this for inclusion in 8u342 during rampdown as 17u already has it since the April update and 11u now has this backport. It would be good for 8u to be consistent as soon as possible.

Mac issue is JDK-8286989 which will be fixed when b04 is promoted.

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

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

From andrew at openjdk.java.net  Tue May 31 02:58:48 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 31 May 2022 02:58:48 GMT
Subject: [jdk8u-dev] RFR: 8235385: Crash on aarch64 JDK due to long offset
 [v3]
In-Reply-To: <ugtAbdBk1MzQLVbJQ5-W4wmMEzcXNvkW8auCAqFx3WI=.b5194acd-287a-4c07-90d9-4e8af586cc35@github.com>
References: <_jge4fRsRjD-AhR_7WvVEr-zQLDFObOrp3W6dC5EDqA=.e9241905-acb7-470f-93a0-12192e9c97f6@github.com>
 <ugtAbdBk1MzQLVbJQ5-W4wmMEzcXNvkW8auCAqFx3WI=.b5194acd-287a-4c07-90d9-4e8af586cc35@github.com>
Message-ID: <6XejVQwDbdQDWC_tSPrywsBfoyT-zBv8Ey0Dz9FJ-e8=.b147d0ca-3948-437a-b70d-518862ef9de8@github.com>

On Mon, 4 Apr 2022 10:58:05 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review backport of 8235385 from jdk11u-dev. Original patch is applied with the following changes (except path shuffling):
>> 
>> - the overload of 'loadStore()' updated to be conform with the baseline
>> - fixed baseline conflicts in copyright sections
>> 
>> Verified (18.04.6 LTS/aarch64) with the reproducers from JBS, 10 of 10 runs passed. Aproximately a half of runs crashed before I've applied the patch.
>> 
>> Regression (18.04.6 LTS/aarch64): compiler & runtime
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing extra empty lines

Thanks. This should be good to go now.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/30

From duke at openjdk.java.net  Tue May 31 06:24:26 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Tue, 31 May 2022 06:24:26 GMT
Subject: [jdk8u-dev] Integrated: 8235385: Crash on aarch64 JDK due to long
 offset
In-Reply-To: <_jge4fRsRjD-AhR_7WvVEr-zQLDFObOrp3W6dC5EDqA=.e9241905-acb7-470f-93a0-12192e9c97f6@github.com>
References: <_jge4fRsRjD-AhR_7WvVEr-zQLDFObOrp3W6dC5EDqA=.e9241905-acb7-470f-93a0-12192e9c97f6@github.com>
Message-ID: <JguitNFBdEHtAczlZdlpOEzhHvAescF-16-tqQ-nMeg=.cf719a4f-2035-4140-88af-16ee68d2e903@github.com>

On Mon, 4 Apr 2022 06:14:30 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Hi!
> 
> Please review backport of 8235385 from jdk11u-dev. Original patch is applied with the following changes (except path shuffling):
> 
> - the overload of 'loadStore()' updated to be conform with the baseline
> - fixed baseline conflicts in copyright sections
> 
> Verified (18.04.6 LTS/aarch64) with the reproducers from JBS, 10 of 10 runs passed. Aproximately a half of runs crashed before I've applied the patch.
> 
> Regression (18.04.6 LTS/aarch64): compiler & runtime

This pull request has now been integrated.

Changeset: 820ab134
Author:    Alexey Pavlyutkin <apavlyutkin at azul.com>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/820ab134927cb76c61cf9c144637d18e0e2a4f2c
Stats:     694 lines in 3 files changed: 628 ins; 37 del; 29 mod

8235385: Crash on aarch64 JDK due to long offset
8287508: The tests added to jdk-8 by 8235385 are to be ported to jdk-11

Co-authored-by: Wang Zhuo <wzhuo at openjdk.org>
Co-authored-by: Andrew Haley <aph at openjdk.org>
Reviewed-by: aph, andrew
Backport-of: 156c486e920b1ca406064dd189562b830990f7f9

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/30

From zgu at openjdk.java.net  Tue May 31 14:02:16 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 31 May 2022 14:02:16 GMT
Subject: [jdk8u-dev] RFR: 8287537: 8u JDK-8284620 backport broke AArch64 build
Message-ID: <DwsCoHwGLh8SYMBHNxOXI0EQCJDo7Q41eGwCmHJvrN8=.0dcf23f0-f24f-48d5-8cf5-e1c403cb743d@github.com>

The original backport is bad, sorry.

Test:

- [x] built on Linux x86_64
- [x] build on AArch64 (Raspberry Pi) w/o patch.

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

Commit messages:
 - 8287537: 8u JDK-8284620 backport broke AArch64 build

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/69

From andrew at openjdk.java.net  Tue May 31 14:56:55 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 31 May 2022 14:56:55 GMT
Subject: [jdk8u-dev] RFR: 8287537: 8u JDK-8284620 backport broke AArch64
 build
In-Reply-To: <DwsCoHwGLh8SYMBHNxOXI0EQCJDo7Q41eGwCmHJvrN8=.0dcf23f0-f24f-48d5-8cf5-e1c403cb743d@github.com>
References: <DwsCoHwGLh8SYMBHNxOXI0EQCJDo7Q41eGwCmHJvrN8=.0dcf23f0-f24f-48d5-8cf5-e1c403cb743d@github.com>
Message-ID: <tXJWV5XfMpaLaLJdEaxHS0nTYdoAqbNp5_J6aYdni1E=.9570135e-7b88-4582-a115-c46c94f25f72@github.com>

On Tue, 31 May 2022 13:53:37 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> The original backport is bad, sorry.
> 
> Test:
> 
> - [x] built on Linux x86_64
> - [x] build on AArch64 (Raspberry Pi) w/o patch.

I'll run this with my build and see if it fixes the crash on AArch64 there.

This is a regression fix for 8u342, so the PR will need to be filed against https://github.com/openjdk/jdk8u instead and `jdk8u-critical-request` used on the bug. 8u-dev will then pick it up when I promote b05.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/69

From andrew at openjdk.java.net  Tue May 31 15:11:11 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 31 May 2022 15:11:11 GMT
Subject: [jdk8u] RFR: 8285591: [11] add signum checks in DSA.java
 engineVerify [v2]
In-Reply-To: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
References: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
Message-ID: <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>

> This change was part of a security fix, JDK-8277233, for 17u during the April update.  The rest of 8277233 did not apply to older releases, as it concerned code added to ` src/jdk.crypto.ec/share/classes/sun/security/ec/ECDSAOperations.java` by JDK-8237218 in 15u.
> 
> However, the additional checks in `src/java.base/share/classes/sun/security/provider/DSA.java` that were included in the patch are applicable to older releases.
> 
> I'm raising this for inclusion in 8u342 during rampdown as 17u already has it since the April update and 11u now has this backport. It would be good for 8u to be consistent as soon as possible.

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

 - Merge remote-tracking branch 'jdk8u/master' into JDK-8285591
 - Backport bf3438c5dc993b96d089cabb5318bfc64a6904a3

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u/pull/11/files
  - new: https://git.openjdk.java.net/jdk8u/pull/11/files/7178fffa..424f2fc8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk8u&pr=11&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk8u&pr=11&range=00-01

  Stats: 1036 lines in 44 files changed: 525 ins; 84 del; 427 mod
  Patch: https://git.openjdk.java.net/jdk8u/pull/11.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u pull/11/head:pull/11

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