From andrew at openjdk.java.net  Wed Jun  1 02:29:38 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 1 Jun 2022 02:29:38 GMT
Subject: [jdk8u-dev] RFR: 8087283: Add support for the XML Signature here()
 function to the JDK XPath implementation
In-Reply-To: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
References: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
Message-ID: <_dgYpqpi3jQaVYBGbE06fnt4O1QPs7bcPcazTKsXASU=.6bf73955-4b82-4762-822b-d2638cddac32@github.com>

On Mon, 30 May 2022 12:11:43 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> 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.

What is present in this backport looks ok.  However, there are a couple of omissions from the version in 11u:
* The copyright changes to `jaxp/src/com/sun/org/apache/xpath/internal/compiler/Keywords.java` are missing. Comparing the current 8u & 11u versions show the change is needed.
* This fix actually spans two commits, because it was done under the old split repository / forest setup. The other commit is [b05b9cb](https://github.com/openjdk/jdk11u/commit/b05b9cbefad137c5e2802942de6e77d3994f4315)

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

Changes requested by andrew (Reviewer).

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

From yan at openjdk.java.net  Wed Jun  1 07:43:37 2022
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Wed, 1 Jun 2022 07:43:37 GMT
Subject: [jdk8u-dev] RFR: 8087283: Add support for the XML Signature here()
 function to the JDK XPath implementation
In-Reply-To: <_dgYpqpi3jQaVYBGbE06fnt4O1QPs7bcPcazTKsXASU=.6bf73955-4b82-4762-822b-d2638cddac32@github.com>
References: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
 <_dgYpqpi3jQaVYBGbE06fnt4O1QPs7bcPcazTKsXASU=.6bf73955-4b82-4762-822b-d2638cddac32@github.com>
Message-ID: <-0EudsHP5Yvb3_7VRyUBXuVvr6DVLy6ulSR_X66bpOY=.3bfd3498-7299-41c3-99a1-d9cd77fbb80b@github.com>

On Wed, 1 Jun 2022 02:25:45 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> 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.
>
> What is present in this backport looks ok.  However, there are a couple of omissions from the version in 11u:
> * The copyright changes to `jaxp/src/com/sun/org/apache/xpath/internal/compiler/Keywords.java` are missing. Comparing the current 8u & 11u versions show the change is needed.
> * This fix actually spans two commits, because it was done under the old split repository / forest setup. The other commit is [b05b9cb](https://github.com/openjdk/jdk11u/commit/b05b9cbefad137c5e2802942de6e77d3994f4315)

Thank you @gnu-andrew ! As to the copyright, in the current (before the fix) version of jdk8u it is virtually the same as in 22fad6452 new part of the 1st Keywords.java hunk (and in 11u) barring some formatting difference (lines are shorter in 11u). I've used 22fad6452 so decided to skip the hunk altogether (the old part of the hunk differs significantly).

The fixupFunctionTable() part, yes, I've missed it, thank you, retesting locally first...

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

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

From yan at openjdk.java.net  Wed Jun  1 08:11:31 2022
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Wed, 1 Jun 2022 08:11:31 GMT
Subject: [jdk8u-dev] RFR: 8087283: Add support for the XML Signature here()
 function to the JDK XPath implementation [v2]
In-Reply-To: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
References: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
Message-ID: <9W9gKrawvxihnOait5KaLM6EnqXz-hVr1U9f3JDgkhI=.2a0bb42c-ecff-457b-b714-3856c76112f2@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.

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

  Added XalanXPathAPI checking part of 8087283

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/67/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/67/files/eea608a7..66839fab

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

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 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 clanger at openjdk.java.net  Wed Jun  1 11:11:43 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 1 Jun 2022 11:11:43 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: <vGAJJ_ZxSZpdSzy7zYO4j5m7n_fAa_DZ2_vREb8TNnw=.3c2c143e-a20f-433d-8e2a-1a76101cb921@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

> /issue add 8287508

Hm, why did you add this issue here? (Question also goes to @gnu-andrew). Now https://bugs.openjdk.java.net/browse/JDK-8287508 is marked as resolved although no tests have yet been backported there.

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

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

From dongbohe at openjdk.java.net  Wed Jun  1 12:08:17 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Wed, 1 Jun 2022 12:08:17 GMT
Subject: [jdk8u-dev] RFR: 8067941: [TESTBUG] Fix tests for OS with 64K page
 size.
Message-ID: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>

Hi,

I would like to backport this patch to fix tests for OS with 64K page size.
Patch does not apply cleanly: 
JDK-8062854[1] move StackOverflowBug.java and Test8009761.java to corresponding subfolders.
Test8009761.java context is different because JDK-8021775[2] and JDK-8011397[3] doesn't in jdk8u.
Change to TestGCLogMessages.java is excluded because it was added in JDK-8027962[4].
Chnage to WBStackSize.java is excluded because JDK-8032970[5] does not exist in 8.

I changed Xss in StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java, 
StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java and TestStackBangRbp.java from
392k to 512k according to JDK-8159335[6], because JDK-8173339[7] changed StackShadowPages to 20, xss needs at least 456k.

Testing: checked that StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java,
StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java, TestStackBangRbp.java,
TestHumongousAllocInitialMark.java, TestCMSHeapSizeFlags.java, TestG1HeapSizeFlags.java,
TestParallelHeapSizeFlags.java, TestSerialHeapSizeFlags.java fails without the patch
and passes with the patch on Aarch64 with 64K page size.


[1] https://bugs.openjdk.java.net/browse/JDK-8062854
[2] https://bugs.openjdk.java.net/browse/JDK-8021775
[3] https://bugs.openjdk.java.net/browse/JDK-8011397
[4] https://bugs.openjdk.java.net/browse/JDK-8027962
[5] https://bugs.openjdk.java.net/browse/JDK-8032970
[6] https://bugs.openjdk.java.net/browse/JDK-8159335
[7] https://bugs.openjdk.java.net/browse/JDK-8173339

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

Depends on: https://git.openjdk.java.net/jdk8u-dev/pull/66

Commit messages:
 - Backport 8e2df5f543522866e7c27ff95ea6fb6458393682

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

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

From dongbohe at openjdk.java.net  Wed Jun  1 12:28:32 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Wed, 1 Jun 2022 12:28:32 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: <KjFu30c0accRP2tJB38U_QzBRnacrL-oPpuoOrX6xeg=.a0915807-23d1-4728-a4c6-241a95dbfd3f@github.com>

On Mon, 30 May 2022 03:22:04 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this patch to fix minimum stack size computations on AArch64.
> I updated the value directly on `define_pd_global` because [JDK-8078556](https://bugs.openjdk.java.net/browse/JDK-8078556) is not in 8u.
> 
> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 4k page size.
> Following test case worked correctly after patch.
> Before patch:
> $ java TLSStackOverflow
> [1]    35476 segmentation fault (core dumped) java TLSStackOverflow
> After patch:
> $ java TLSStackOverflow
> got expected stackoverflow, passed
> 
> $ keytool -genkey -keyalg RSA -keystore localhost-rsa.jks -storepass changeit -storetype pkcs12
> $ cat TLSStackOverflow.java
> 
> import javax.net.ServerSocketFactory;
> import javax.net.SocketFactory;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.net.Socket;
> import java.security.KeyStore;
> import java.security.KeyStoreException;
> import java.security.NoSuchAlgorithmException;
> import java.security.SecureRandom;
> import java.security.cert.CertificateException;
> import java.security.cert.X509Certificate;
> 
> public class TLSStackOverflow
> {
> 
>     private static final String keystore = "/home/hedongbo/myprojects/study/stackoverflow/new/localhost-rsa.jks";
>     private static final char[] passphrase = "changeit".toCharArray();
>     private static final int port = 8447;
> 
>     private static KeyStore pfx = null;
> 
>     public static void doWrite(OutputStream out) throws Exception {
>         out.write("hello".getBytes(), 0, 3);
>         out.flush();
>         doWrite(out);
>     }
> 
>     public TLSStackOverflow()
>     {}
> 
>     public static void main(String[] args) throws Exception
>     {
>         new Thread(() -> {
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 KeyManager[] kms = kmf.getKeyManagers();
>                 ctx.init(kms, null, null);
>                 ServerSocketFactory fact = ctx.getServerSocketFactory();
>                 SSLServerSocket serversocket = (SSLServerSocket) fact.createServerSocket(port);
>                 while (true)
>                 {
>                     Socket socket = null;
>                     try
>                     {
>                         socket = serversocket.accept();
> 
>                         DataInputStream in = new DataInputStream(socket.getInputStream());
>                         DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                         byte[] buf = new byte[8192];
>                         int len = in.read(buf);
>                     }
>                     catch (Exception e)
>                     {
>                         e.printStackTrace();
>                     }
>                     finally
>                     {
> //                        try
> //                        {
> //                            socket.close();
> //                        }
> //                        catch (Exception e) {
> //                            e.printStackTrace();
> //                        }
>                     }
>                 }
>             } catch (Exception e) {
>                 e.printStackTrace();
>             }
>         }).start();
> 
>         Thread.sleep(2000);
> 
>         new Thread(() -> {
>             SSLSocket socket = null;
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 TrustAllManager[] trust = { new TrustAllManager() };
>                 ctx.init(null, trust, null);
>                 SocketFactory fact = ctx.getSocketFactory();
>                 socket = (SSLSocket) fact.createSocket();
>                 socket.connect(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 2000);
>                 socket.setTcpNoDelay(true);
>                 socket.startHandshake();
> 
>                 DataInputStream in = new DataInputStream(socket.getInputStream());
>                 DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                 String s = "GET " + " HTTP/1.1\r\n";
>                 s+= "Accept: */*\r\n";
>                 s+= "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)\r\n";
>                 s+= "Connection: Close\r\n";
>                 s+= "\r\n";
>                 try {
>                     doWrite(out);
>                 } catch (StackOverflowError e) {
>                     System.out.println("got expected stackoverflow, passed");
>                     System.exit(0);
>                 }
> 
>                 byte[] buf = new byte[8192];
>                 int len = in.read(buf);
>                 if (len == -1)
>                 {
>                     System.out.println("eof");
>                     return;
>                 }
>                 System.out.println(new String(buf, 0, len));
>             }
>             catch (Exception e)
>             {
>                 e.printStackTrace();
>             }
>             finally
>             {
>                 try
>                 {
>                     socket.close();
>                 }
>                 catch (Exception e)
>                 {}
>             }
> 
>         }).start();
> 
>     }
> 
> }
> 
> 
> class TrustAllManager implements X509TrustManager
> {
>     private X509Certificate[] issuers;
> 
>     public TrustAllManager()
>     {
>         this.issuers = new X509Certificate[0];
>     }
> 
>     public X509Certificate[] getAcceptedIssuers()
>     {
>         return issuers ;
>     }
> 
>     public void checkClientTrusted(X509Certificate[] chain, String authType)
>     {}
> 
>     public void checkServerTrusted(X509Certificate[] chain, String authType)
>     {}
> }

I found that some test cases fail on OS with 64k page size, and launched a PR #71  to fix these test cases.

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

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

From aph at openjdk.java.net  Wed Jun  1 12:32:41 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 1 Jun 2022 12:32:41 GMT
Subject: [jdk8u-dev] RFR: 8166140: C1: Possible integer overflow in
 LIRGenerator::generate_address on several platforms
In-Reply-To: <bewq2-9tRiBHq9XBksQrrPdbPxmvODqIXWOC1ae9jfg=.38d18744-9790-404a-b5ae-cfd346309d92@github.com>
References: <bewq2-9tRiBHq9XBksQrrPdbPxmvODqIXWOC1ae9jfg=.38d18744-9790-404a-b5ae-cfd346309d92@github.com>
Message-ID: <HY5AUKGAy1_33yHlqy8XiPB7YCvaHDCma6Qbk4RBWtM=.06cdeacb-6d08-4ef6-a7f4-c0c58aa34b22@github.com>

On Fri, 22 Apr 2022 12:00:12 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to backport this patch to 8u for parity with Oracle 8u331.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166140
> Patch: [http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f6c1ea29110e](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f6c1ea29110e)
> 
> The patch does not apply cleanly:
> 1. ppc does not have compiler port in 8u.
> 2. Changes for `LIRGenerator::emit_array_address()` in `c1_LIRGenerator_x86.cpp` is obsoleted by [JDK-8272014](https://github.com/openjdk/jdk8u-dev/commit/3e26fd987a70473778e9ae06aa8dd5054483fa59)
> 
> Original code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014517.html

That looks right. I've just gone through the Assembler entry points to make sure that all of them really do take a 64-bit integer type. There has been some churn in this area.

This looks OK:


Assembler::operand_valid_for_add_sub_immediate((long imm)
Address::offset_ok_for_immed((int64_t offset, uint shift)


And AFAICS there's no truncation to int anywhere in the path. But please check too.

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

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

From duke at openjdk.java.net  Wed Jun  1 14:45:38 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Wed, 1 Jun 2022 14:45:38 GMT
Subject: [jdk8u-dev] RFR: 8235385: Crash on aarch64 JDK due to long offset
 [v3]
In-Reply-To: <vGAJJ_ZxSZpdSzy7zYO4j5m7n_fAa_DZ2_vREb8TNnw=.3c2c143e-a20f-433d-8e2a-1a76101cb921@github.com>
References: <_jge4fRsRjD-AhR_7WvVEr-zQLDFObOrp3W6dC5EDqA=.e9241905-acb7-470f-93a0-12192e9c97f6@github.com>
 <ugtAbdBk1MzQLVbJQ5-W4wmMEzcXNvkW8auCAqFx3WI=.b5194acd-287a-4c07-90d9-4e8af586cc35@github.com>
 <vGAJJ_ZxSZpdSzy7zYO4j5m7n_fAa_DZ2_vREb8TNnw=.3c2c143e-a20f-433d-8e2a-1a76101cb921@github.com>
Message-ID: <3YdDPu3z0bWAGhw21CiRtj8I09CN94CbpU6KXiDkbIc=.ee5fb128-5d04-416c-94cd-ac614a3a9801@github.com>

On Wed, 1 Jun 2022 11:08:26 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> > /issue add 8287508
> 
> Hm, why did you add this issue here? (Question also goes to @gnu-andrew). Now https://bugs.openjdk.java.net/browse/JDK-8287508 is marked as resolved although no tests have yet been backported there.

I just forgot put the tests attached to 8235385 under Git making backport to 11. They were added on backporting to 8, and 8287508 was raised exactly to port the tests back to 11

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

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

From andrew at openjdk.java.net  Thu Jun  2 01:16:26 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 2 Jun 2022 01:16:26 GMT
Subject: [jdk8u-dev] RFR: 8087283: Add support for the XML Signature here()
 function to the JDK XPath implementation [v2]
In-Reply-To: <_dgYpqpi3jQaVYBGbE06fnt4O1QPs7bcPcazTKsXASU=.6bf73955-4b82-4762-822b-d2638cddac32@github.com>
References: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
 <_dgYpqpi3jQaVYBGbE06fnt4O1QPs7bcPcazTKsXASU=.6bf73955-4b82-4762-822b-d2638cddac32@github.com>
Message-ID: <gce1_pDPikIVXlW8xYMpTkpzebpUhrIHD11WoTNV9xc=.e6f9fb4d-3a15-4388-b3ab-9d1d9ce54b09@github.com>

On Wed, 1 Jun 2022 02:25:45 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Yuri Nesterenko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added XalanXPathAPI checking part of 8087283
>
> What is present in this backport looks ok.  However, there are a couple of omissions from the version in 11u:
> * The copyright changes to `jaxp/src/com/sun/org/apache/xpath/internal/compiler/Keywords.java` are missing. Comparing the current 8u & 11u versions show the change is needed.
> * This fix actually spans two commits, because it was done under the old split repository / forest setup. The other commit is [b05b9cb](https://github.com/openjdk/jdk11u/commit/b05b9cbefad137c5e2802942de6e77d3994f4315)

> Thank you @gnu-andrew ! As to the copyright, in the current (before the fix) version of jdk8u it is virtually the same as in 22fad6452 new part of the 1st Keywords.java hunk (and in 11u) barring some formatting difference (lines are shorter in 11u). I've used 22fad6452 so decided to skip the hunk altogether (the old part of the hunk differs significantly).

Right, what I'd suggest is just copying over Keywords.java from 11u. After this patch, they are the same bar minor formatting differences which came after this patch, which means `FUNC_HERE_STRING` is formatted differently to all the other constant declarations in the file (thank JDK-8068842 for this) I don't see any reason to keep these differences and they will only make any future patches which touch the file more difficult to apply.

> 
> The fixupFunctionTable() part, yes, I've missed it, thank you, retesting locally first...

Easy to miss as it was in a different commit. Version here looks fine with the logging changes.

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

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

From yan at openjdk.java.net  Thu Jun  2 07:08:26 2022
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Thu, 2 Jun 2022 07:08:26 GMT
Subject: [jdk8u-dev] RFR: 8087283: Add support for the XML Signature here()
 function to the JDK XPath implementation [v3]
In-Reply-To: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
References: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
Message-ID: <ol0D5SMRWEygds_D2tvxFRgpLCoDYOSd8EJwEjRhj2Q=.bc5b98ae-1c69-436f-81a5-2290dd10f0f9@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.

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

  Make Keywords.java a copy of 11u state

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/67/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/67/files/66839fab..047219d6

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

  Stats: 19 lines in 1 file changed: 4 ins; 0 del; 15 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 yan at openjdk.java.net  Thu Jun  2 07:08:26 2022
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Thu, 2 Jun 2022 07:08:26 GMT
Subject: [jdk8u-dev] RFR: 8087283: Add support for the XML Signature here()
 function to the JDK XPath implementation [v2]
In-Reply-To: <9W9gKrawvxihnOait5KaLM6EnqXz-hVr1U9f3JDgkhI=.2a0bb42c-ecff-457b-b714-3856c76112f2@github.com>
References: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
 <9W9gKrawvxihnOait5KaLM6EnqXz-hVr1U9f3JDgkhI=.2a0bb42c-ecff-457b-b714-3856c76112f2@github.com>
Message-ID: <EVZMkOJLD_vLh2pTk-MHvCqIRWo6sknhGySQ4xzQI5w=.bca1d291-747e-44be-84f9-92feddf3d855@github.com>

On Wed, 1 Jun 2022 08:11:31 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

>> 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.
>
> Yuri Nesterenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added XalanXPathAPI checking part of 8087283

You are right: this current state of copyright preamble etc. is a result of some reformatting in before-10 jdk, and nobody will backport that cleanup -- perhaps several of them -- as such. Updated.

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

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

From omikhaltcova at openjdk.java.net  Thu Jun  2 19:51:22 2022
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Thu, 2 Jun 2022 19:51:22 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: <igEAunp5w24x3GQOfY_oAnWWcs7ZR0VJcS9s9ryLlYs=.bc670e79-e428-4d82-baca-19c00ba5c41e@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

Anton, thanks for the hint and the valuable explanation!
I reran ModifierRobotKeyTest.java and AltGraphModifierTest.java (modified by JDK-8155742) on Windows, MacOS and Linux. Before the fix they fail for all platforms. After the fix they pass only for Windows (JDK-8155742 was opened only for Windows). Your experience mentioned above does not inspire me with much optimism on this way but obviously additional investigation is needed how to fix these tests' failures on MacOS and Linux.
Concerning RightAltKeyTest.java it fails before this fix and passes after.

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

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

From dholmes at openjdk.java.net  Thu Jun  2 21:23:33 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Jun 2022 21:23:33 GMT
Subject: [jdk8u-ri] Integrated: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
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: <2_nRcTUugVzp9cAVCPn7UPaDEVPS2_xG5ijsklOFp8w=.cafc70b6-f0e7-41c5-b9a5-c36f0bd58585@github.com>

On Tue, 24 May 2022 02:40:32 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

This pull request has now been integrated.

Changeset: 0d4cfc09
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-ri/commit/0d4cfc090c651786535529acfe5acb0209cb1d3d
Stats:     574 lines in 25 files changed: 98 ins; 364 del; 112 mod

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

Reviewed-by: mchung, iris

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

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

From andrew at openjdk.java.net  Fri Jun  3 00:58:38 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Fri, 3 Jun 2022 00:58:38 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: <M4787zp5M46sgRWRKdaBLAm00DSPurLi6KDvWu8MYjw=.cab57e31-705f-49c3-828d-b1abf21eea10@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.

Fix is in 11u: https://git.openjdk.java.net/jdk11u-dev/commit/a2e64948eb12089bd45c2b734c405ead87977276

Awaiting response to my previous comments and test runs.

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

Changes requested by andrew (Reviewer).

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

From andrew at openjdk.java.net  Fri Jun  3 01:47:42 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Fri, 3 Jun 2022 01:47:42 GMT
Subject: [jdk8u-dev] RFR: 8087283: Add support for the XML Signature here()
 function to the JDK XPath implementation [v3]
In-Reply-To: <ol0D5SMRWEygds_D2tvxFRgpLCoDYOSd8EJwEjRhj2Q=.bc5b98ae-1c69-436f-81a5-2290dd10f0f9@github.com>
References: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
 <ol0D5SMRWEygds_D2tvxFRgpLCoDYOSd8EJwEjRhj2Q=.bc5b98ae-1c69-436f-81a5-2290dd10f0f9@github.com>
Message-ID: <qBz0bCzH862XASW2tHlfP_Ns4fHHbnU9duaDbkEBdsw=.f9cfa694-efdd-4f16-97d8-20e4bbf64aee@github.com>

On Thu, 2 Jun 2022 07:08:26 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

>> 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.
>
> Yuri Nesterenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make Keywords.java a copy of 11u state

Thanks for persisting with these changes. The new version looks fine to me (and I agree the Mac failure is a very odd infra issue!)

Please flag the bug with `jdk8u-fix-request` and I'll approve.

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

Marked as reviewed by andrew (Reviewer).

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

From andrew at openjdk.java.net  Fri Jun  3 01:56:28 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Fri, 3 Jun 2022 01:56:28 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows [v2]
In-Reply-To: <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
 <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
Message-ID: <hoL6DueMhZarHsHyLxL3mhcr1T9OR3WLnfep1QU-NgA=.f6794ea5-a9b8-442f-a5ea-fafe92358fff@github.com>

On Fri, 13 May 2022 17:38:41 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
>
> 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

I can approve this now once `jdk8u-fix-request` is added to the bug.

To clarify; I just meant the one `PRAGMA_FORMAT_MUTE_WARNINGS_FOR_GCC` removal in the file being altered, not the rest of that huge patch. In theory, the changes mean that file should now compile without warnings and so the pragma is redundant. But this is something was can do under a separate bug.

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

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

From yan at openjdk.java.net  Fri Jun  3 09:38:37 2022
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Fri, 3 Jun 2022 09:38:37 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: <YBdASUL-kBFv5V2bCtRkMkp0hlloZUk33uA6gUW4-uQ=.b4326c89-ed36-4798-8a34-277ae336c5ff@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

Marked as reviewed by yan (Reviewer).

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

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

From duke at openjdk.java.net  Fri Jun  3 09:49:45 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Fri, 3 Jun 2022 09:49:45 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: <lkdu4PO7YKa09yqUU9DQOhCJphWkuKGMZd_E3muzkfQ=.d67b450b-7eff-4334-a468-4e52d6a5c4df@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 omikhaltcova at openjdk.java.net  Fri Jun  3 11:00:25 2022
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 3 Jun 2022 11:00:25 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v5]
In-Reply-To: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
Message-ID: <5Rx8OcNP9Ae5WAIjUACg4ICz0EUoQqRyDnVLtw3vCxc=.27fe04bd-f39e-43d3-981f-62517ceca767@github.com>

> 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:

  Update file permission

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/60/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/60/files/ace410e2..d0f4a65d

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

  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 Jun  3 13:28:39 2022
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 3 Jun 2022 13:28:39 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v5]
In-Reply-To: <5Rx8OcNP9Ae5WAIjUACg4ICz0EUoQqRyDnVLtw3vCxc=.27fe04bd-f39e-43d3-981f-62517ceca767@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
 <5Rx8OcNP9Ae5WAIjUACg4ICz0EUoQqRyDnVLtw3vCxc=.27fe04bd-f39e-43d3-981f-62517ceca767@github.com>
Message-ID: <_QEztObZsrw62U-idcp5KUOgYLSoP0R7m7Ylfm79au4=.ef5f9eaf-3ee9-444d-839c-de342b8ce06a@github.com>

On Fri, 3 Jun 2022 11:00:25 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:
> 
>   Update file permission

The build for macOS was broken and fixed by https://github.com/openjdk/jdk8u-dev/pull/61. 
It was verified locally.

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

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

From andrew at openjdk.java.net  Fri Jun  3 15:35:41 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Fri, 3 Jun 2022 15:35:41 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: <nLyNKz_YSgZ_VK29UzeOQHe_PQtuc8VK0_EfdiiOdd8=.bb74d22d-b7fd-4e90-ba18-2378a7c224b3@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.

This fixes the build for me. Please file against openjdk/jdk8u so we can get this in ASAP.

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

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

From sgehwolf at openjdk.java.net  Fri Jun  3 16:41:59 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 3 Jun 2022 16:41:59 GMT
Subject: [jdk8u] RFR: 8285591: [11] add signum checks in DSA.java
 engineVerify [v2]
In-Reply-To: <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>
References: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
 <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>
Message-ID: <fQWLK7Ozsae8DKtgY9cai6toCt5gdsD6QGe8kVLokO0=.62418810-b083-4928-85e1-e805c6f5537f@github.com>

On Tue, 31 May 2022 15:11:11 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.
>
> 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

LGTM. It would be good if Martin could have a look too.

@martinuy Could you please review this?

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

Marked as reviewed by sgehwolf (Reviewer).

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

From zgu at openjdk.java.net  Fri Jun  3 16:47:14 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 3 Jun 2022 16:47:14 GMT
Subject: [jdk8u] RFR: 8287537: 8u JDK-8284620 backport broke AArch64 build
Message-ID: <LYw9TESpqybOHbhWH-OQ4VmH52jTM8zxXgDXTO-6aXk=.ec5d3c00-ef34-47d8-bca4-8f5379aee00d@github.com>

Please review this patch that fixes a bad backport.

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

Commit messages:
 - 8287537: 8u JDK-8284620 backport broke AArch64 build

Changes: https://git.openjdk.java.net/jdk8u/pull/12/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u&pr=12&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/pull/12.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u pull/12/head:pull/12

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

From andrew at openjdk.java.net  Fri Jun  3 16:52:47 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Fri, 3 Jun 2022 16:52:47 GMT
Subject: [jdk8u] RFR: 8287537: 8u JDK-8284620 backport broke AArch64 build
In-Reply-To: <LYw9TESpqybOHbhWH-OQ4VmH52jTM8zxXgDXTO-6aXk=.ec5d3c00-ef34-47d8-bca4-8f5379aee00d@github.com>
References: <LYw9TESpqybOHbhWH-OQ4VmH52jTM8zxXgDXTO-6aXk=.ec5d3c00-ef34-47d8-bca4-8f5379aee00d@github.com>
Message-ID: <791xf-lRoyjiVNP6O3TutpfUyKZT775k8xUcW9jyNJU=.4845d80e-c860-4bbf-9115-9d2078c99f57@github.com>

On Fri, 3 Jun 2022 16:42:53 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this patch that fixes a bad backport.

Same as https://github.com/openjdk/jdk8u-dev/pull/69 and fixes build on AArch64

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

Marked as reviewed by andrew (Reviewer).

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

From zgu at openjdk.java.net  Fri Jun  3 16:54:02 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 3 Jun 2022 16:54:02 GMT
Subject: [jdk8u] Integrated: 8287537: 8u JDK-8284620 backport broke AArch64
 build
In-Reply-To: <LYw9TESpqybOHbhWH-OQ4VmH52jTM8zxXgDXTO-6aXk=.ec5d3c00-ef34-47d8-bca4-8f5379aee00d@github.com>
References: <LYw9TESpqybOHbhWH-OQ4VmH52jTM8zxXgDXTO-6aXk=.ec5d3c00-ef34-47d8-bca4-8f5379aee00d@github.com>
Message-ID: <97PH3aoMLL9Xpukesj0n8sJCEn962mlGYiGq2CjJnnk=.4e8a189a-8e3e-40a8-916f-778527c31bd5@github.com>

On Fri, 3 Jun 2022 16:42:53 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this patch that fixes a bad backport.

This pull request has now been integrated.

Changeset: 95962f14
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u/commit/95962f141c996834e9f12cd8780a2f6e0c56d782
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8287537: 8u JDK-8284620 backport broke AArch64 build

Reviewed-by: andrew

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

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

From duke at openjdk.java.net  Mon Jun  6 06:06:27 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Mon, 6 Jun 2022 06:06:27 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: <waduLw2QS5BcFPYAfQCvvDjuqbJPW1vHrM82LORzXaM=.0d12b250-e643-46f0-bf25-6645fe6b486e@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 this PR please?

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

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

From mbalao at openjdk.java.net  Mon Jun  6 14:35:01 2022
From: mbalao at openjdk.java.net (Martin Balao)
Date: Mon, 6 Jun 2022 14:35:01 GMT
Subject: [jdk8u] RFR: 8285591: [11] add signum checks in DSA.java
 engineVerify [v2]
In-Reply-To: <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>
References: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
 <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>
Message-ID: <aW7FNlBhXGkyKxIYKVrCd9SVgb2HtNSfCa3szwByiis=.b1ce22d2-d425-4a21-a5a5-24daf1ea72a1@github.com>

On Tue, 31 May 2022 15:11:11 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.
>
> 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

I will look into this today.

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

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

From mbalao at openjdk.java.net  Mon Jun  6 14:47:42 2022
From: mbalao at openjdk.java.net (Martin Balao)
Date: Mon, 6 Jun 2022 14:47:42 GMT
Subject: [jdk8u] RFR: 8285591: [11] add signum checks in DSA.java
 engineVerify [v2]
In-Reply-To: <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>
References: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
 <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>
Message-ID: <CtfGSghTe1MAJUgPcN6w_Gmg_mjgrwi-A4G5Wv13wHg=.1af99020-33ad-4236-be62-e091d8480e37@github.com>

On Tue, 31 May 2022 15:11:11 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.
>
> 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

LGTM.

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

Marked as reviewed by mbalao (Reviewer).

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

From serb at openjdk.java.net  Mon Jun  6 22:27:13 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 6 Jun 2022 22:27:13 GMT
Subject: [jdk8u-dev] RFR: 8194873: right ALT key hotkeys no longer work in
 Swing components [v5]
In-Reply-To: <5Rx8OcNP9Ae5WAIjUACg4ICz0EUoQqRyDnVLtw3vCxc=.27fe04bd-f39e-43d3-981f-62517ceca767@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
 <5Rx8OcNP9Ae5WAIjUACg4ICz0EUoQqRyDnVLtw3vCxc=.27fe04bd-f39e-43d3-981f-62517ceca767@github.com>
Message-ID: <le0tMFgXMnbZSofGTY2NASP3WJgaRVQJ-xBNRcNA71M=.57d59581-af18-4564-abfa-37f8e3a52ffd@github.com>

On Fri, 3 Jun 2022 11:00:25 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:
> 
>   Update file permission

Marked as reviewed by serb (Reviewer).

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

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

From andrew at openjdk.java.net  Tue Jun  7 01:54:11 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 7 Jun 2022 01:54:11 GMT
Subject: [jdk8u] RFR: 8285591: [11] add signum checks in DSA.java
 engineVerify [v2]
In-Reply-To: <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>
References: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
 <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>
Message-ID: <dY-eN23bH9IyPytwnf3Uv7gRgpHHMGeftLSEY8bX5gs=.1136f9a5-1817-4ad5-9db3-71f31a904804@github.com>

On Tue, 31 May 2022 15:11:11 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.
>
> 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

Thanks. Flagged with `jdk8u-critical-request`.

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

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

From akasko at openjdk.java.net  Tue Jun  7 12:19:17 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Tue, 7 Jun 2022 12:19:17 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows [v2]
In-Reply-To: <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
 <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
Message-ID: <FrrRkpQHZT63BqetYzDCOtKuDUCFKpu9UPnqCCcMYPI=.847ea82f-3a3c-4a96-ba5d-204c54e7155b@github.com>

On Fri, 13 May 2022 17:38:41 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
>
> Alex Kasko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8280963: Incorrect PrintFlags formatting on Windows

Thanks for the review! I've added fix request label to the bug.

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

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

From andrew at openjdk.java.net  Wed Jun  8 01:49:50 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 8 Jun 2022 01:49:50 GMT
Subject: [jdk8u] RFR: 8285591: [11] add signum checks in DSA.java
 engineVerify [v2]
In-Reply-To: <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>
References: <gjuCnpTOmHLwcg2VRtBKwBVVNgZGTnDBcS9lxIyDz0c=.2f78c02d-75b0-4d4b-be23-30c067a8220f@github.com>
 <HqTIy_QNRReMBcpI3yH0-hWYD_jCBToi65rKdL492ac=.9f90363b-e6ec-410c-9bc2-335cb624ecf3@github.com>
Message-ID: <yfph0pFh4lOBnc9-qnsLrqoGLETpFK9myG50ARKkuH0=.d58dd151-8069-4bb7-9f6f-b92361c233f2@github.com>

On Tue, 31 May 2022 15:11:11 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.
>
> 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

I see `jdk8u-critical-yes`

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

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

From andrew at openjdk.java.net  Wed Jun  8 01:49:52 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 8 Jun 2022 01:49:52 GMT
Subject: [jdk8u] Integrated: 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: <jzMSvsNC9NWMBtdGGJ2vxH7-QfqaLzK_qxxyy8Tr0v0=.b1199989-a3ba-419c-8db0-f9e93ef01b0f@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.

This pull request has now been integrated.

Changeset: a18e9043
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u/commit/a18e9043fa2a0a14098e1ec25d32577aaac6c023
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8285591: [11] add signum checks in DSA.java engineVerify

Reviewed-by: sgehwolf, mbalao
Backport-of: bf3438c5dc993b96d089cabb5318bfc64a6904a3

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

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

From duke at openjdk.java.net  Fri Jun 10 06:38:14 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Fri, 10 Jun 2022 06:38:14 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: <iXXN4ubNl3HPiBQ1CDC_WmkYCQKG3J5XHgVUUifmlzY=.aac72815-3b39-481c-9003-46224d34e81d@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

@phohensee 
Is it ok if I integrate?

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

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

From sgehwolf at openjdk.java.net  Fri Jun 10 10:13:15 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 10 Jun 2022 10:13:15 GMT
Subject: [jdk8u-dev] RFR: 8130895: Test
 javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
In-Reply-To: <iXXN4ubNl3HPiBQ1CDC_WmkYCQKG3J5XHgVUUifmlzY=.aac72815-3b39-481c-9003-46224d34e81d@github.com>
References: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
 <iXXN4ubNl3HPiBQ1CDC_WmkYCQKG3J5XHgVUUifmlzY=.aac72815-3b39-481c-9003-46224d34e81d@github.com>
Message-ID: <1w2m_EUWciITVrPX4F8JtsofAoQT2RAjckqRtSH_0Ag=.0ef33237-6d81-4f22-99ca-1b981f21c9cb@github.com>

On Fri, 10 Jun 2022 06:34:08 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
>
> @phohensee 
> Is it ok if I integrate?

@ktakakuri You need to apply for approval of the bug. Add a `Fix Request` comment explaining why the fix is needed and what the risks are. Also add a `jdk8u-fix-request` label so that maintainers will see the request. Once you have `jdk8u-fix-yes` on the bug you can integrate.

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

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

From duke at openjdk.java.net  Mon Jun 13 07:10:10 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Mon, 13 Jun 2022 07:10:10 GMT
Subject: [jdk8u-dev] RFR: 8130895: Test
 javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
In-Reply-To: <iXXN4ubNl3HPiBQ1CDC_WmkYCQKG3J5XHgVUUifmlzY=.aac72815-3b39-481c-9003-46224d34e81d@github.com>
References: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
 <iXXN4ubNl3HPiBQ1CDC_WmkYCQKG3J5XHgVUUifmlzY=.aac72815-3b39-481c-9003-46224d34e81d@github.com>
Message-ID: <wdRacgODCrSr6xbrYXi1_H1Mv5zgbyCzfZFh8JpBkFY=.056deccf-7904-41ac-b626-66ae6c0f10e1@github.com>

On Fri, 10 Jun 2022 06:34:08 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
>
> @phohensee 
> Is it ok if I integrate?

> @ktakakuri You need to apply for approval of the bug. Add a `Fix Request` comment explaining why the fix is needed and what the risks are. Also add a `jdk8u-fix-request` label so that maintainers will see the request. Once you have `jdk8u-fix-yes` on the bug you can integrate.

Thank you for your comment.
I am concerned about the lack of reviewers.

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

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

From sgehwolf at openjdk.java.net  Mon Jun 13 08:32:58 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 13 Jun 2022 08:32:58 GMT
Subject: [jdk8u-dev] RFR: 8130895: Test
 javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
In-Reply-To: <wdRacgODCrSr6xbrYXi1_H1Mv5zgbyCzfZFh8JpBkFY=.056deccf-7904-41ac-b626-66ae6c0f10e1@github.com>
References: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
 <iXXN4ubNl3HPiBQ1CDC_WmkYCQKG3J5XHgVUUifmlzY=.aac72815-3b39-481c-9003-46224d34e81d@github.com>
 <wdRacgODCrSr6xbrYXi1_H1Mv5zgbyCzfZFh8JpBkFY=.056deccf-7904-41ac-b626-66ae6c0f10e1@github.com>
Message-ID: <rPWNmalkWO_3YNgGQw_42hRSzdfffHL-laHQRpz62OE=.5085a266-a182-42fc-8fa6-7fbdad7a00ca@github.com>

On Mon, 13 Jun 2022 07:07:02 GMT, ktakakuri <duke at openjdk.java.net> wrote:

>> @phohensee 
>> Is it ok if I integrate?
>
>> @ktakakuri You need to apply for approval of the bug. Add a `Fix Request` comment explaining why the fix is needed and what the risks are. Also add a `jdk8u-fix-request` label so that maintainers will see the request. Once you have `jdk8u-fix-yes` on the bug you can integrate.
> 
> Thank you for your comment.
> I am concerned about the lack of reviewers.

@ktakakuri Unfortunately, the OpenJDK wiki is offline at the moment due to an ongoing migration. Our wiki page explains this. In a nutshell, clean backports don't need a separate review. So in your case only maintainer approval is needed. That's what the label process described above is for. Only modified patches need a review. I take it you've run tests on relevant platforms and have seen no regressions?

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

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

From akasko at openjdk.java.net  Tue Jun 14 08:29:55 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Tue, 14 Jun 2022 08:29:55 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows [v2]
In-Reply-To: <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
 <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
Message-ID: <9MVQAPFUnuwQhAORLKq4nzXt74DePnb_aAe6paaLkxs=.ddfc65eb-6bbc-4647-bef5-c3b906fc3d4c@github.com>

On Fri, 13 May 2022 17:38:41 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
>
> Alex Kasko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8280963: Incorrect PrintFlags formatting on Windows

Thanks for the approval! It is not clear whether macOS pre-submit check must pass for integrate command to work, will try it now.

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

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

From akasko at openjdk.java.net  Tue Jun 14 08:33:55 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Tue, 14 Jun 2022 08:33:55 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows [v2]
In-Reply-To: <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
 <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
Message-ID: <J4Z52SUfmdOsnOILwc2iaZpgmw7P-u64E8fKt5MYwjo=.af0cefd9-7efb-4ace-ab7b-8a25fcd0c02e@github.com>

On Fri, 13 May 2022 17:38:41 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
>
> Alex Kasko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8280963: Incorrect PrintFlags formatting on Windows

Apparently PR needs to be "ready" for integrate to work, any hints what can I do for it to have a "ready" mark?

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

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

From sgehwolf at openjdk.java.net  Tue Jun 14 09:55:04 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 14 Jun 2022 09:55:04 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows [v2]
In-Reply-To: <J4Z52SUfmdOsnOILwc2iaZpgmw7P-u64E8fKt5MYwjo=.af0cefd9-7efb-4ace-ab7b-8a25fcd0c02e@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
 <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
 <J4Z52SUfmdOsnOILwc2iaZpgmw7P-u64E8fKt5MYwjo=.af0cefd9-7efb-4ace-ab7b-8a25fcd0c02e@github.com>
Message-ID: <3kBlaFpoFPt8lHmVvXQu6mPsM4ZblfQPFfIMjdcf9RA=.8ce6e179-ff09-4a9c-9ebb-777f020c897e@github.com>

On Tue, 14 Jun 2022 08:30:52 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> Apparently PR needs to be "ready" for integrate to work, any hints what can I do for it to have a "ready" mark?

It needs an actual "Approve" via the `Review changes` button. I don't see it here.

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

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

From duke at openjdk.java.net  Tue Jun 14 21:01:43 2022
From: duke at openjdk.java.net (duke)
Date: Tue, 14 Jun 2022 21:01:43 GMT
Subject: [jdk8u-dev] Withdrawn: 8186902: jcmd GC.run should not be blocked by
 DisableExplicitGC
In-Reply-To: <CO7wy96H9oqfljcxe24Ed5o3xlmeGRegEOi_jkoRLns=.57a79b1c-d8de-4b79-91fc-e0a5873aa4bc@github.com>
References: <CO7wy96H9oqfljcxe24Ed5o3xlmeGRegEOi_jkoRLns=.57a79b1c-d8de-4b79-91fc-e0a5873aa4bc@github.com>
Message-ID: <lMy1flZimjIRpGWi_IY6b-s5stSOCl-ZzY5vKodlUvM=.a5a1d9fe-3bac-4b4d-898b-63cfa52d406c@github.com>

On Tue, 19 Apr 2022 13:31:24 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to backport this parity bug to openjdk8u.
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8186902
> Original patch: 
> [http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/3d1150c7899c](https://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/3d1150c7899c)
> 
> 
> The original patch does not apply cleanly. Besides line shifts, 8u does 
> not define `GCCause::_dcmd_gc_run`, but `GCCause::_java_lang_system_gc` instead.
> 
> Original code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-September/014288.html

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Tue Jun 14 21:03:43 2022
From: duke at openjdk.java.net (duke)
Date: Tue, 14 Jun 2022 21:03:43 GMT
Subject: [jdk8u-dev] Withdrawn: 8065895: Synchronous signals during error
 reporting may terminate or hang VM process
In-Reply-To: <0Vn1Ez7yOsUtPcv4csXii-UtPDKa0RXAXMJQDn5yvbQ=.67da286d-0c31-4634-bf27-f8f418c3f9d2@github.com>
References: <0Vn1Ez7yOsUtPcv4csXii-UtPDKa0RXAXMJQDn5yvbQ=.67da286d-0c31-4634-bf27-f8f418c3f9d2@github.com>
Message-ID: <mgXwpdlJ2S2xUkkzEw7R1FKFi33tvCVVZOHk5kAAlCQ=.0f3f179a-4ba5-4c82-a9b2-6c8704e91578@github.com>

On Tue, 19 Apr 2022 13:17:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to backport this patch to openjdk8u for parity with Oracle 
> 8u321.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8065895
> jdk9 patch: [http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6bfc40057b3f](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6bfc40057b3f)
> 
> 
> jdk9 patch does not apply cleanly. There is only one conflict in 
> `debug.cpp`, due to line shifts.
> 
> Original cod review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-July/014133.html
> and it has been reviewed by the author @stuefe (not a jdk8u reviewer)

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Tue Jun 14 21:05:51 2022
From: duke at openjdk.java.net (duke)
Date: Tue, 14 Jun 2022 21:05:51 GMT
Subject: [jdk8u-dev] Withdrawn: 8275811: Incorrect instance to dispose
In-Reply-To: <TOn1dlA-AObukIk8TAzbMyIFTPS_GlXDW9W7mr2zPQU=.15718c0f-a363-4aac-be9c-cdcfd7285299@github.com>
References: <TOn1dlA-AObukIk8TAzbMyIFTPS_GlXDW9W7mr2zPQU=.15718c0f-a363-4aac-be9c-cdcfd7285299@github.com>
Message-ID: <93wsVCIcalsysKiJuIQiVwafebs7mT1RnzoSQDA-cIM=.683e6836-ee32-4ee6-a666-3122e95738af@github.com>

On Tue, 19 Apr 2022 12:55:41 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to backport this patch for parity with Oracle 8u331.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8275811
> Patch: https://github.com/openjdk/jdk/commit/cddc6ce44695cba4614c3405eb2b194d7c76489b
> 
> The original patch does not apply cleanly to 8u. The only conflicts are 
> in `OutputRecord.java`, due to line shifts. Resolved manually.
> 
> Origin code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014478.html
> 
> Test:
> 
> - [x] jdk_security, no new failure

This pull request has been closed without being integrated.

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

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

From andrew at openjdk.java.net  Wed Jun 15 01:06:47 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 15 Jun 2022 01:06:47 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows [v2]
In-Reply-To: <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
 <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
Message-ID: <0LsvmC1yvgXl5_PjM_LK8wV9wJcLkzB92FJPNGUyDEE=.ee25834d-e56e-44fb-ad37-417129bb764a@github.com>

On Fri, 13 May 2022 17:38:41 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
>
> 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

Marked as reviewed by andrew (Reviewer).

Done. This would be simpler if the approval process was integrated with SKARA.

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

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

From andrew at openjdk.java.net  Wed Jun 15 01:09:52 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 15 Jun 2022 01:09:52 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows [v2]
In-Reply-To: <9MVQAPFUnuwQhAORLKq4nzXt74DePnb_aAe6paaLkxs=.ddfc65eb-6bbc-4647-bef5-c3b906fc3d4c@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
 <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
 <9MVQAPFUnuwQhAORLKq4nzXt74DePnb_aAe6paaLkxs=.ddfc65eb-6bbc-4647-bef5-c3b906fc3d4c@github.com>
Message-ID: <gWZi21U4RgUSfNdsNBGJNnCCe7f02AOOKTN4dBDz6XY=.7e81c879-5fa6-45d0-a250-bfa6445d1607@github.com>

On Tue, 14 Jun 2022 08:26:34 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> Thanks for the approval! It is not clear whether macOS pre-submit check must pass for integrate command to work, will try it now.

The MacOS failure is unrelated and is already fixed in jdk8u-dev. You can confirm this by merging with 8u-dev yourself, but it's not really necessary.

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

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

From andrew at openjdk.java.net  Wed Jun 15 01:09:53 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 15 Jun 2022 01:09:53 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows [v2]
In-Reply-To: <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
 <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
Message-ID: <Cc2eEtnj2FEvekaF46G-sZu0DemOeoEjL1C_DR4NdVE=.bd2e2102-06b3-4663-a3bc-4a8f2f7bf744@github.com>

On Fri, 13 May 2022 17:38:41 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
>
> Alex Kasko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8280963: Incorrect PrintFlags formatting on Windows

Specifically, "https://github.com/openjdk/jdk8u-dev/commit/c5f96be5e370f01fbb8677049e2feeeeb3b3012d: 8286989: Build failure on macOS after 8281814"

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

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

From duke at openjdk.java.net  Wed Jun 15 03:59:42 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 15 Jun 2022 03:59:42 GMT
Subject: [jdk8u-dev] Withdrawn: 8129940: JRadioButton does not honor
 non-standard FocusTraversalKeys
In-Reply-To: <wK6jPnFflLU4aeXDYOweQuKDpXW-B8lEQYlYD7ugxeA=.f3e108e4-9d38-4712-9c85-5e255ad17445@github.com>
References: <wK6jPnFflLU4aeXDYOweQuKDpXW-B8lEQYlYD7ugxeA=.f3e108e4-9d38-4712-9c85-5e255ad17445@github.com>
Message-ID: <gjaV-qMDpGWVIbjpCl1DVxXE867N9Vi_zGjvYAOZRF8=.a9357056-5440-440f-a69d-c8f89cf64a97@github.com>

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

> I would like to backport this patch to openjdk8u for parity with Oracle 
> 8u311.
> 
> The original bug: https://bugs.openjdk.java.net/browse/JDK-8129940
> The original patch: 
> [http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fbf897c33625](https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fbf897c33625)
> 
> The jdk9 patch does not apply cleanly, but only conflict is copyright 
> year of `BasicRadioButtonUI.java` file.
> 
> Test:
> - [x] Included `FocusTraversal/FocusTraversal.java` test fails without patch and passes with it on Linux x86_64

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Wed Jun 15 06:26:46 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Wed, 15 Jun 2022 06:26:46 GMT
Subject: [jdk8u-dev] RFR: 8130895: Test
 javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
In-Reply-To: <wdRacgODCrSr6xbrYXi1_H1Mv5zgbyCzfZFh8JpBkFY=.056deccf-7904-41ac-b626-66ae6c0f10e1@github.com>
References: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
 <iXXN4ubNl3HPiBQ1CDC_WmkYCQKG3J5XHgVUUifmlzY=.aac72815-3b39-481c-9003-46224d34e81d@github.com>
 <wdRacgODCrSr6xbrYXi1_H1Mv5zgbyCzfZFh8JpBkFY=.056deccf-7904-41ac-b626-66ae6c0f10e1@github.com>
Message-ID: <c5PwK2SHQUNdPpWI_rGcf3Tv_KXQ8F5586rBkaRmrAY=.43036672-d912-4e70-ae79-72761eee2ef1@github.com>

On Mon, 13 Jun 2022 07:07:02 GMT, ktakakuri <duke at openjdk.java.net> wrote:

>> @phohensee 
>> Is it ok if I integrate?
>
>> @ktakakuri You need to apply for approval of the bug. Add a `Fix Request` comment explaining why the fix is needed and what the risks are. Also add a `jdk8u-fix-request` label so that maintainers will see the request. Once you have `jdk8u-fix-yes` on the bug you can integrate.
> 
> Thank you for your comment.
> I am concerned about the lack of reviewers.

> @ktakakuri Unfortunately, the OpenJDK wiki is offline at the moment due to an ongoing migration. Our wiki page explains this. In a nutshell, clean backports don't need a separate review. So in your case only maintainer approval is needed. That's what the label process described above is for. Only modified patches need a review. I take it you've run tests on relevant platforms and have seen no regressions?

Thank you, that makes sense.
I added the Fix-request label.

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

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

From duke at openjdk.java.net  Wed Jun 15 11:02:44 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 15 Jun 2022 11:02:44 GMT
Subject: [jdk8u-dev] Withdrawn: 8233019: java.lang.Class.isPrimitive() (C1)
 returns wrong result if Klass* is aligned to 32bit
In-Reply-To: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
References: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
Message-ID: <1wtqS8pxcwvpIWVDH9Hm9Hekdb9k_K8R-LGYJ9l_HX4=.11598435-41c3-4e15-a787-8580ce029ac9@github.com>

On Wed, 20 Apr 2022 09:14:28 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this as follow up of [JDK-8150669](https://bugs.openjdk.java.net/browse/JDK-8150669)
> This resolves the corner case that leads to incorrect result for C1 intrinsic,
> 
> Original patch for 11u: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/e1b6631cbd2f 
> Patch does not apply cleanly to 8u: arm and s390 ports are not there and we don?t have c1 compiler support in ppc port in 8u.
> 
> Performed full jtreg test both on x86_64-linux-gnu and aarch64-linux-gnu platforms. 
> (I made this PR on behalf of fyang)
> 
> Thanks,
> hedongbo

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Wed Jun 15 11:05:47 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 15 Jun 2022 11:05:47 GMT
Subject: [jdk8u-dev] Withdrawn: 8150669: C1 intrinsic for Class.isPrimitive
In-Reply-To: <xjKQPs3ITjdlBkX3b2zkgPaJa-55PmBmEyGIeAFLx6w=.a4283cdb-2aad-415c-817c-52ce867b5362@github.com>
References: <xjKQPs3ITjdlBkX3b2zkgPaJa-55PmBmEyGIeAFLx6w=.a4283cdb-2aad-415c-817c-52ce867b5362@github.com>
Message-ID: <9NwXHZnEWV0yoyzQkQ9-ZS3gEorW-tIv2jk3CsbIaxY=.32870517-8465-419d-a926-ae5e9bc55e07@github.com>

On Tue, 19 Apr 2022 08:42:37 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi, 
> 
> Please review this backport. The original purpose is to backport fix for [JDK-8239477](https://bugs.openjdk.java.net/browse/JDK-8239477). But this depends on fix for [JDK-8150669](https://bugs.openjdk.java.net/browse/JDK-8150669) & [JDK-8233019](https://bugs.openjdk.java.net/browse/JDK-8233019).
> 
> Performed full jtreg test both on x86_64-linux-gnu and aarch64-linux-gnu platforms. 
> 
> This PR has been reviewed by Paul and approved before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-August/014155.html
> 
> Follow-up fix [JDK-8233019](https://bugs.openjdk.java.net/browse/JDK-8233019) is planned to be backported as well.
> 
> (I made this PR on behalf of fyang)
> 
> Thanks,
> hedongbo

This pull request has been closed without being integrated.

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

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

From akasko at openjdk.java.net  Wed Jun 15 11:28:40 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Wed, 15 Jun 2022 11:28:40 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on
 Windows [v2]
In-Reply-To: <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
References: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>
 <95zsQX4y2su5B5sOc3196u64G_iVTSvx0-bjD-pnoJA=.16e6493c-be82-49c3-846c-8684970805a3@github.com>
Message-ID: <bYHAgQzsA_WL1dHsSG_PTU5jcj3_ZL9JOXggjo3CzpQ=.dc41c9de-1de0-4c41-af06-a23763a2fcdd@github.com>

On Fri, 13 May 2022 17:38:41 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
>
> Alex Kasko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8280963: Incorrect PrintFlags formatting on Windows

Thanks for the clarification!

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

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

From akasko at openjdk.java.net  Wed Jun 15 11:28:42 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Wed, 15 Jun 2022 11:28:42 GMT
Subject: [jdk8u-dev] Integrated: 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: <_J5Ho4eMbb8eDrWS790BYuEUlSSrFqxRiJP5D6S0Gis=.ac235552-9753-4186-a757-84aa17177187@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 pull request has now been integrated.

Changeset: 83e90957
Author:    Alex Kasko <akasko at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/83e90957bef15267bed792ee5d8d65899a2487e8
Stats:     53 lines in 2 files changed: 50 ins; 0 del; 3 mod

8280963: Incorrect PrintFlags formatting on Windows

Reviewed-by: andrew

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

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

From dsamersoff at openjdk.java.net  Wed Jun 15 14:56:31 2022
From: dsamersoff at openjdk.java.net (Dmitry Samersoff)
Date: Wed, 15 Jun 2022 14:56:31 GMT
Subject: [jdk8u-dev] RFR: 8288483: JAVA_TOOL_OPTIONS are silently truncated if
 they exceed 1024 bytes
Message-ID: <Zw8terG4gPrNMI1FSn5GdoofjDrrZWHJ3xJ6UZfFaug=.1592c6cf-b9bc-429a-8c27-afb709637c4b@github.com>

? bytes

The JAVA_TOOL_OPTIONS environment variable is used to pass additional JVM arguments.

The current implementation in jdk8 has an internal limit on the length of the option variable (1024 bytes) and the number of options (64).

A longer variable will be silently truncated and some options will be lost or the VM will exist with an unrecognized option error. 

The fix is not a direct backport of the changes in the later JDKs, but I kept the code as close as possible to what we have in the latest jdk.

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

Commit messages:
 - 8288483: JAVA_TOOL_OPTIONS are silently truncated if they exceed 1024 bytes

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

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

From jbachorik at openjdk.java.net  Wed Jun 15 15:49:50 2022
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 15 Jun 2022 15:49:50 GMT
Subject: [jdk8u-dev] RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee
Message-ID: <dUtP1EByyqoRHSRLWcoErKDekZTpQADy6bpYG-Wwee0=.cc0e8bd0-0ccf-4f32-8b8e-901d85653a59@github.com>

8283849: AsyncGetCallTrace may crash JVM on guarantee

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

Commit messages:
 - Backport 19639855311a47ed532547743ea3873eb8b016d3

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

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

From dsamersoff at openjdk.java.net  Wed Jun 15 17:28:55 2022
From: dsamersoff at openjdk.java.net (Dmitry Samersoff)
Date: Wed, 15 Jun 2022 17:28:55 GMT
Subject: [jdk8u-dev] RFR: 8288483: JAVA_TOOL_OPTIONS are silently truncated
 if they exceed 1024 bytes
In-Reply-To: <Zw8terG4gPrNMI1FSn5GdoofjDrrZWHJ3xJ6UZfFaug=.1592c6cf-b9bc-429a-8c27-afb709637c4b@github.com>
References: <Zw8terG4gPrNMI1FSn5GdoofjDrrZWHJ3xJ6UZfFaug=.1592c6cf-b9bc-429a-8c27-afb709637c4b@github.com>
Message-ID: <BiwEVt1_1dC5fozWWCllWuzpa7snzdZmbuCYtoVnX0U=.9240b468-e83f-45cb-b846-8f84cadc8986@github.com>

On Wed, 15 Jun 2022 14:31:29 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> ? bytes
> 
> The JAVA_TOOL_OPTIONS environment variable is used to pass additional JVM arguments.
> 
> The current implementation in jdk8 has an internal limit on the length of the option variable (1024 bytes) and the number of options (64).
> 
> A longer variable will be silently truncated and some options will be lost or the VM will exist with an unrecognized option error. 
> 
> The fix is not a direct backport of the changes in the later JDKs, but I kept the code as close as possible to what we have in the latest jdk.

Closing to redo from a separate branch

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

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

From dsamersoff at openjdk.java.net  Wed Jun 15 17:28:55 2022
From: dsamersoff at openjdk.java.net (Dmitry Samersoff)
Date: Wed, 15 Jun 2022 17:28:55 GMT
Subject: [jdk8u-dev] Withdrawn: 8288483: JAVA_TOOL_OPTIONS are silently
 truncated if they exceed 1024 bytes
In-Reply-To: <Zw8terG4gPrNMI1FSn5GdoofjDrrZWHJ3xJ6UZfFaug=.1592c6cf-b9bc-429a-8c27-afb709637c4b@github.com>
References: <Zw8terG4gPrNMI1FSn5GdoofjDrrZWHJ3xJ6UZfFaug=.1592c6cf-b9bc-429a-8c27-afb709637c4b@github.com>
Message-ID: <SngGYxD9wA5VoK2eXhz4jIN0wGVYHRMqs-5knHby2u4=.c29cfefb-d165-4f42-a2be-16ae1cebe5d3@github.com>

On Wed, 15 Jun 2022 14:31:29 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> ? bytes
> 
> The JAVA_TOOL_OPTIONS environment variable is used to pass additional JVM arguments.
> 
> The current implementation in jdk8 has an internal limit on the length of the option variable (1024 bytes) and the number of options (64).
> 
> A longer variable will be silently truncated and some options will be lost or the VM will exist with an unrecognized option error. 
> 
> The fix is not a direct backport of the changes in the later JDKs, but I kept the code as close as possible to what we have in the latest jdk.

This pull request has been closed without being integrated.

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

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

From dsamersoff at openjdk.java.net  Wed Jun 15 17:41:55 2022
From: dsamersoff at openjdk.java.net (Dmitry Samersoff)
Date: Wed, 15 Jun 2022 17:41:55 GMT
Subject: [jdk8u-dev] RFR: 8288483: JAVA_TOOL_OPTIONS are silently truncated if
 they exceed 1024 bytes
Message-ID: <doh2szKRvHfymPCU86E9FzicsbOJLYfsjbI7s6YWdb8=.d7468dda-c918-472a-9fcc-96bacc92a1cd@github.com>

The JAVA_TOOL_OPTIONS environment variable is used to pass additional JVM arguments.

The current implementation in jdk8 has an internal limit on the length of the option variable (1024 bytes) and the number of options (64).

A longer variable will be silently truncated and some options will be lost or the VM will exist with an unrecognized option error.

The fix is not a direct backport of the changes in the later JDKs, but I kept the code as close as possible to what we have in the latest jdk.

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

Commit messages:
 - 8288483: JAVA_TOOL_OPTIONS are silently truncated if they exceed 1024 bytes

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

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

From dongbohe at openjdk.java.net  Thu Jun 16 02:03:05 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Thu, 16 Jun 2022 02:03:05 GMT
Subject: [jdk8u-dev] RFR: 8233019: java.lang.Class.isPrimitive() (C1)
 returns wrong result if Klass* is aligned to 32bit [v2]
In-Reply-To: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
References: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
Message-ID: <PmL_KO9ti3tQpSnm-qSMNv4Swp_yQXzIhAReMxME3wk=.bb56f4be-ec8a-43d5-a7ed-d5839b2d19e5@github.com>

> Hi,
> 
> I would like to backport this as follow up of [JDK-8150669](https://bugs.openjdk.java.net/browse/JDK-8150669)
> This resolves the corner case that leads to incorrect result for C1 intrinsic,
> 
> Original patch for 11u: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/e1b6631cbd2f 
> Patch does not apply cleanly to 8u: arm and s390 ports are not there and we don?t have c1 compiler support in ppc port in 8u.
> 
> Performed full jtreg test both on x86_64-linux-gnu and aarch64-linux-gnu platforms. 
> (I made this PR on behalf of fyang)
> 
> 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 8233019
 - b67ca938f37f952e53f73d2e0b8ebcaf96139fda
 - Backport 890f94d7e6be731ac2ebae2f1ad3cc20ec836115

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/43/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/43/files/d1ef6921..0ac67b30

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

  Stats: 5719 lines in 124 files changed: 3959 ins; 856 del; 904 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/43.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/43/head:pull/43

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

From dongbohe at openjdk.java.net  Thu Jun 16 02:03:12 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Thu, 16 Jun 2022 02:03:12 GMT
Subject: [jdk8u-dev] RFR: 8150669: C1 intrinsic for Class.isPrimitive [v2]
In-Reply-To: <xjKQPs3ITjdlBkX3b2zkgPaJa-55PmBmEyGIeAFLx6w=.a4283cdb-2aad-415c-817c-52ce867b5362@github.com>
References: <xjKQPs3ITjdlBkX3b2zkgPaJa-55PmBmEyGIeAFLx6w=.a4283cdb-2aad-415c-817c-52ce867b5362@github.com>
Message-ID: <Y_0Iht_YlYNLjdofvo_TAAkLrkACpAAI3U8wlvpZo9o=.5409a720-6d7a-4f60-ab95-5a8a81847ee3@github.com>

> Hi, 
> 
> Please review this backport. The original purpose is to backport fix for [JDK-8239477](https://bugs.openjdk.java.net/browse/JDK-8239477). But this depends on fix for [JDK-8150669](https://bugs.openjdk.java.net/browse/JDK-8150669) & [JDK-8233019](https://bugs.openjdk.java.net/browse/JDK-8233019).
> 
> Performed full jtreg test both on x86_64-linux-gnu and aarch64-linux-gnu platforms. 
> 
> This PR has been reviewed by Paul and approved before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-August/014155.html
> 
> Follow-up fix [JDK-8233019](https://bugs.openjdk.java.net/browse/JDK-8233019) is planned to be backported as well.
> 
> (I made this PR on behalf of fyang)
> 
> 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 8150669
 - Backport 890f94d7e6be731ac2ebae2f1ad3cc20ec836115

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/37/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/37/files/3418e09e..c14c86c2

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

  Stats: 5719 lines in 124 files changed: 3959 ins; 856 del; 904 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/37.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/37/head:pull/37

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

From dongbohe at openjdk.java.net  Thu Jun 16 02:38:48 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Thu, 16 Jun 2022 02:38:48 GMT
Subject: [jdk8u-dev] RFR: 8233019: java.lang.Class.isPrimitive() (C1)
 returns wrong result if Klass* is aligned to 32bit [v3]
In-Reply-To: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
References: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
Message-ID: <Qhc6aZo4dwu84MZbGB6nRgZbme9wFcoaRwem2ZKH4ZY=.c83f9e44-436b-4f45-8af4-195ef9c9961c@github.com>

> Hi,
> 
> I would like to backport this as follow up of [JDK-8150669](https://bugs.openjdk.java.net/browse/JDK-8150669)
> This resolves the corner case that leads to incorrect result for C1 intrinsic,
> 
> Original patch for 11u: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/e1b6631cbd2f 
> Patch does not apply cleanly to 8u: arm and s390 ports are not there and we don?t have c1 compiler support in ppc port in 8u.
> 
> Performed full jtreg test both on x86_64-linux-gnu and aarch64-linux-gnu platforms. 
> (I made this PR on behalf of fyang)
> 
> 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 branch '8150669' into 8233019
 - b67ca938f37f952e53f73d2e0b8ebcaf96139fda

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

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

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

From duke at openjdk.java.net  Thu Jun 16 05:38:11 2022
From: duke at openjdk.java.net (duke)
Date: Thu, 16 Jun 2022 05:38:11 GMT
Subject: [jdk8u-dev] Withdrawn: 8146215: (fs)
 java/nio/file/Files/probeContentType/Basic.java failed frequently on
 Solaris-sparc with Unexpected type: text/plain
In-Reply-To: <3rS5sGUvp1NafbhBEtFzkVNzTlGsytk9XEnDGqSHRqU=.82f5f510-7b89-462e-aa5b-782d52351a7c@github.com>
References: <3rS5sGUvp1NafbhBEtFzkVNzTlGsytk9XEnDGqSHRqU=.82f5f510-7b89-462e-aa5b-782d52351a7c@github.com>
Message-ID: <L-YoAo6PASsoQTxEjLmtz7I_IvMgPddVCGOjFKTMEWY=.d38602fe-1cf1-48a2-8999-fdb5b6237cd5@github.com>

On Wed, 20 Apr 2022 20:53:51 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> Backport of a NIO fix.
> 
> Original commit on jdk9: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/44bb7c7997ca
> 
> Patch does not apply cleanly, differences from original commit: paths reshuffling, copyright year in
> AbstractFileTypeDetector.java, list of issues numbers changed and checkOSXContentTypes() function removed in Basic.java test.
> 
> Related mailing list threads:
> 
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012050.html
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-October/014321.html
> 
> Testing:
> 
>  - [x] jtreg:java/nio/file/Files/
>  - [x] jtreg:java/net/URLConnection/

This pull request has been closed without being integrated.

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

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

From phh at openjdk.org  Thu Jun 16 20:05:51 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 16 Jun 2022 20:05:51 GMT
Subject: [jdk8u-dev] RFR: 8283849: AsyncGetCallTrace may crash JVM on
 guarantee
In-Reply-To: <dUtP1EByyqoRHSRLWcoErKDekZTpQADy6bpYG-Wwee0=.cc0e8bd0-0ccf-4f32-8b8e-901d85653a59@github.com>
References: <dUtP1EByyqoRHSRLWcoErKDekZTpQADy6bpYG-Wwee0=.cc0e8bd0-0ccf-4f32-8b8e-901d85653a59@github.com>
Message-ID: <zOHpqRZ9fBTfTLmqF3LepZpSRG82xYeNCGhltOoeGBM=.59f40151-ff4e-4836-a24d-91202bc9dc04@github.com>

On Wed, 15 Jun 2022 14:40:52 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

> This backport required some changes in the original changeset due to:
> - different source structure (the affected files are physically located in a different file hierarchy)
> - missing `current_thread->as_java_thread()` method - fully replaceable by `((JavaThread*)current_thread)` cast
> - missing `Thread::current_or_null_safe()` - replaced by `Thread::curent_or_null()` which has 100% same implementation as `Thread::current_or_null_safe()` in JDK 17

Lgtm.

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

Marked as reviewed by phh (Reviewer).

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

From phh at openjdk.org  Thu Jun 16 20:49:59 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 16 Jun 2022 20:49:59 GMT
Subject: [jdk8u-dev] RFR: 8150669: C1 intrinsic for Class.isPrimitive [v2]
In-Reply-To: <Y_0Iht_YlYNLjdofvo_TAAkLrkACpAAI3U8wlvpZo9o=.5409a720-6d7a-4f60-ab95-5a8a81847ee3@github.com>
References: <xjKQPs3ITjdlBkX3b2zkgPaJa-55PmBmEyGIeAFLx6w=.a4283cdb-2aad-415c-817c-52ce867b5362@github.com>
 <Y_0Iht_YlYNLjdofvo_TAAkLrkACpAAI3U8wlvpZo9o=.5409a720-6d7a-4f60-ab95-5a8a81847ee3@github.com>
Message-ID: <jZuhwlaSF9m37s4VUvu0bzLclJz9FS1JJqgY-z7rb4o=.2e0ea1ee-59f7-4ed3-8625-03f75e24367a@github.com>

On Thu, 16 Jun 2022 02:03:12 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi, 
>> 
>> Please review this backport. The original purpose is to backport fix for [JDK-8239477](https://bugs.openjdk.java.net/browse/JDK-8239477). But this depends on fix for [JDK-8150669](https://bugs.openjdk.java.net/browse/JDK-8150669) & [JDK-8233019](https://bugs.openjdk.java.net/browse/JDK-8233019).
>> 
>> Performed full jtreg test both on x86_64-linux-gnu and aarch64-linux-gnu platforms. 
>> 
>> This PR has been reviewed by Paul and approved before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-August/014155.html
>> 
>> Follow-up fix [JDK-8233019](https://bugs.openjdk.java.net/browse/JDK-8233019) is planned to be backported as well.
>> 
>> (I made this PR on behalf of fyang)
>> 
>> 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 8150669
>  - Backport 890f94d7e6be731ac2ebae2f1ad3cc20ec836115

Lgtm.

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

Marked as reviewed by phh (Reviewer).

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

From phh at openjdk.org  Thu Jun 16 20:50:56 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 16 Jun 2022 20:50:56 GMT
Subject: [jdk8u-dev] RFR: 8233019: java.lang.Class.isPrimitive() (C1)
 returns wrong result if Klass* is aligned to 32bit [v3]
In-Reply-To: <Qhc6aZo4dwu84MZbGB6nRgZbme9wFcoaRwem2ZKH4ZY=.c83f9e44-436b-4f45-8af4-195ef9c9961c@github.com>
References: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
 <Qhc6aZo4dwu84MZbGB6nRgZbme9wFcoaRwem2ZKH4ZY=.c83f9e44-436b-4f45-8af4-195ef9c9961c@github.com>
Message-ID: <RodTfaw9cQ_-0gD44sOgV57g7-BkvwTtCfQNq13tQm8=.5db48acc-7dc9-4487-a049-9c27d69ef790@github.com>

On Thu, 16 Jun 2022 02:38:48 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this as follow up of [JDK-8150669](https://bugs.openjdk.java.net/browse/JDK-8150669)
>> This resolves the corner case that leads to incorrect result for C1 intrinsic,
>> 
>> Original patch for 11u: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/e1b6631cbd2f 
>> Patch does not apply cleanly to 8u: arm and s390 ports are not there and we don?t have c1 compiler support in ppc port in 8u.
>> 
>> Performed full jtreg test both on x86_64-linux-gnu and aarch64-linux-gnu platforms. 
>> (I made this PR on behalf of fyang)
>> 
>> 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 branch '8150669' into 8233019
>  - b67ca938f37f952e53f73d2e0b8ebcaf96139fda

Lgtm.

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

Marked as reviewed by phh (Reviewer).

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

From phh at openjdk.org  Thu Jun 16 22:24:53 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 16 Jun 2022 22:24:53 GMT
Subject: [jdk8u-dev] RFR: 8288483: JAVA_TOOL_OPTIONS are silently truncated
 if they exceed 1024 bytes
In-Reply-To: <doh2szKRvHfymPCU86E9FzicsbOJLYfsjbI7s6YWdb8=.d7468dda-c918-472a-9fcc-96bacc92a1cd@github.com>
References: <doh2szKRvHfymPCU86E9FzicsbOJLYfsjbI7s6YWdb8=.d7468dda-c918-472a-9fcc-96bacc92a1cd@github.com>
Message-ID: <5lvNdEZ1_TQt5Gx3ivpnu-uxxmqXJ_xkAYg5BJjub_Y=.3c4f2e5d-85ef-4f06-ba14-1c981821fcc3@github.com>

On Wed, 15 Jun 2022 17:34:51 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

> The JAVA_TOOL_OPTIONS environment variable is used to pass additional JVM arguments.
> 
> The current implementation in jdk8 has an internal limit on the length of the option variable (1024 bytes) and the number of options (64).
> 
> A longer variable will be silently truncated and some options will be lost or the VM will exist with an unrecognized option error.
> 
> The fix is not a direct backport of the changes in the later JDKs, but I kept the code as close as possible to what we have in the latest jdk.
> 
> It's partial backport of relevant changes from JDK-8135195, JDK-8074895, JDK-8061999

Nit: in arguments.hpp, move the declaration or parse_arguments_buffer down 2 lines after parse_java_options_environment variable to match tip's relative placement.

Otherwise fine.

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

Changes requested by phh (Reviewer).

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

From scrater at microsoft.com  Thu Jun 16 22:38:56 2022
From: scrater at microsoft.com (Stephanie Crater)
Date: Thu, 16 Jun 2022 22:38:56 +0000
Subject: [EXTERNAL] Re: Port of JEP 386: Alpine Linux Port to jdk8u
In-Reply-To: <c8a5d3bc-199b-b307-44c9-b6087bdb1bbf@bell-sw.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>
 <c8a5d3bc-199b-b307-44c9-b6087bdb1bbf@bell-sw.com>
Message-ID: <DM6PR21MB1610D3A452850E1DEC2B3DD4A1AC9@DM6PR21MB1610.namprd21.prod.outlook.com>

Hi Aleksei,



We do have a significant number of customers using Java 8 on Alpine, so this backport is something that Microsoft would definitely like to see be supported. We would be willing to maintain Alpine Linux in jdk8u. Let me know what you think!



Thanks,

Stephanie

From: Aleksei Voitylov <aleksei.voitylov at bell-sw.com>
Date: Monday, May 16, 2022 at 5:19 AM
To: Stephanie Crater <scrater at microsoft.com>
Cc: Dalibor Topic <dalibor.topic at oracle.com>, 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
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FLearnAboutSenderIdentification.%255d&amp;data=05%7C01%7Cscrater%40microsoft.com%7Cd58ca2fda4ad43314e2208da37365ad6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637883003859716165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ZLNcw5zvbn2t76m3ZVrdEhHEGgyrGmiOTqdgAzXS%2BPw%3D&amp;reserved=0><https://aka.ms/LearnAboutSenderIdentification.%5d%3chttps:/nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FLearnAboutSenderIdentification.%255d&amp;data=05%7C01%7Cscrater%40microsoft.com%7Cd58ca2fda4ad43314e2208da37365ad6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637883003859716165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ZLNcw5zvbn2t76m3ZVrdEhHEGgyrGmiOTqdgAzXS%2BPw%3D&amp;reserved=0%3e>
>
> 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%7Cd58ca2fda4ad43314e2208da37365ad6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637883003859716165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=gSrkqu%2F2qh6rTx6f1J7Z9V9YYii%2FLqxtfbkQoh1cB8g%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%7Cd58ca2fda4ad43314e2208da37365ad6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637883003859716165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=rxCUkQHM98JXpk0fkaJn36Bqo9APOciYMysP5FOTsuc%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%7Cd58ca2fda4ad43314e2208da37365ad6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637883003859716165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=Chgbgl6%2B5ZQcAV3J2phYw7BeH4UMJXSUXFVqhuBBBys%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%7Cd58ca2fda4ad43314e2208da37365ad6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637883003859716165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=9QzkzNFvwVBqsvSLkQCmwTZnU4ljWfgemQgH2oEoCoQ%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%7Cd58ca2fda4ad43314e2208da37365ad6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637883003859716165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=3mnoZYGts5YbElMCUScjhQXNJgjBLlpOFoEmDjrXsBc%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%7Cd58ca2fda4ad43314e2208da37365ad6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637883003859716165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=P%2BahLARcPY2pPXDv2RxZCKEugF%2FIfWrGYy3fY8S5G9o%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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220616/ae32905b/attachment-0001.htm>

From dsamersoff at openjdk.org  Fri Jun 17 13:08:58 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Fri, 17 Jun 2022 13:08:58 GMT
Subject: [jdk8u-dev] RFR: 8288483: JAVA_TOOL_OPTIONS are silently truncated
 if they exceed 1024 bytes [v2]
In-Reply-To: <doh2szKRvHfymPCU86E9FzicsbOJLYfsjbI7s6YWdb8=.d7468dda-c918-472a-9fcc-96bacc92a1cd@github.com>
References: <doh2szKRvHfymPCU86E9FzicsbOJLYfsjbI7s6YWdb8=.d7468dda-c918-472a-9fcc-96bacc92a1cd@github.com>
Message-ID: <TgEF2-aMqx6mBVNo38st_kXlJAcG1hbmbdA0zIsCo48=.e495814e-dabe-48a9-b52c-68f9bb6188b7@github.com>

> The JAVA_TOOL_OPTIONS environment variable is used to pass additional JVM arguments.
> 
> The current implementation in jdk8 has an internal limit on the length of the option variable (1024 bytes) and the number of options (64).
> 
> A longer variable will be silently truncated and some options will be lost or the VM will exist with an unrecognized option error.
> 
> The fix is not a direct backport of the changes in the later JDKs, but I kept the code as close as possible to what we have in the latest jdk.
> 
> It's partial backport of relevant changes from JDK-8135195, JDK-8074895, JDK-8061999

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

  8288483: JAVA_TOOL_OPTIONS are silently truncated if they exceed 1024 bytes

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/74/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/74/files/172de4c3..efab8d3e

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

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

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

From phh at openjdk.org  Fri Jun 17 13:55:16 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 17 Jun 2022 13:55:16 GMT
Subject: [jdk8u-dev] RFR: 8288483: JAVA_TOOL_OPTIONS are silently truncated
 if they exceed 1024 bytes [v2]
In-Reply-To: <TgEF2-aMqx6mBVNo38st_kXlJAcG1hbmbdA0zIsCo48=.e495814e-dabe-48a9-b52c-68f9bb6188b7@github.com>
References: <doh2szKRvHfymPCU86E9FzicsbOJLYfsjbI7s6YWdb8=.d7468dda-c918-472a-9fcc-96bacc92a1cd@github.com>
 <TgEF2-aMqx6mBVNo38st_kXlJAcG1hbmbdA0zIsCo48=.e495814e-dabe-48a9-b52c-68f9bb6188b7@github.com>
Message-ID: <mnd0GugOipwzGNElRKLYpZO4yHDBx-x2xCvvRLrX1Ak=.e88d18b1-d76d-4a11-8ee5-87b38e3cbe8f@github.com>

On Fri, 17 Jun 2022 13:08:58 GMT, Dmitry Samersoff <dsamersoff at openjdk.org> wrote:

>> The JAVA_TOOL_OPTIONS environment variable is used to pass additional JVM arguments.
>> 
>> The current implementation in jdk8 has an internal limit on the length of the option variable (1024 bytes) and the number of options (64).
>> 
>> A longer variable will be silently truncated and some options will be lost or the VM will exist with an unrecognized option error.
>> 
>> The fix is not a direct backport of the changes in the later JDKs, but I kept the code as close as possible to what we have in the latest jdk.
>> 
>> It's partial backport of relevant changes from JDK-8135195, JDK-8074895, JDK-8061999
>
> Dmitry Samersoff has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8288483: JAVA_TOOL_OPTIONS are silently truncated if they exceed 1024 bytes

Lgtm.

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

Marked as reviewed by phh (Reviewer).

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

From duke at openjdk.org  Mon Jun 20 07:38:23 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Mon, 20 Jun 2022 07:38:23 GMT
Subject: [jdk8u-dev] RFR: 8288718: Requesting backport of JDK-8049228 to JDK 8
Message-ID: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>

8049228: Improve multithreaded scalability of InetAddress cache
7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate

Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

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

Commit messages:
 - 8288718: Requesting backport of JDK-8049228 to JDK 8

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

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

From sgehwolf at openjdk.org  Mon Jun 20 09:47:00 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 20 Jun 2022 09:47:00 GMT
Subject: [jdk8u-dev] RFR: 8288718: Requesting backport of JDK-8049228 to
 JDK 8
In-Reply-To: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
Message-ID: <BkoaoWTNloBcS6LZ-U-cswNJnXufRGHA-gt8P2yn4cs=.9a4061bd-081d-48f5-89e5-4da489c6e369@github.com>

On Wed, 1 Jun 2022 03:41:58 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

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

Please change the PR title to `Backport 250fbb065a789a303d692d698c9b69117bf6cd2c` and close the manual bug you've created for this backport. The original issue will be used instead once you use the said PR title: https://bugs.openjdk.org/browse/JDK-8049228

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

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

From duke at openjdk.org  Mon Jun 20 11:05:00 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Mon, 20 Jun 2022 11:05:00 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache
In-Reply-To: <BkoaoWTNloBcS6LZ-U-cswNJnXufRGHA-gt8P2yn4cs=.9a4061bd-081d-48f5-89e5-4da489c6e369@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <BkoaoWTNloBcS6LZ-U-cswNJnXufRGHA-gt8P2yn4cs=.9a4061bd-081d-48f5-89e5-4da489c6e369@github.com>
Message-ID: <fZRPPyLCqG4RafO2lMDIwkpSzyfoCmlVz-u6PK4nYUk=.5ec8fb06-0127-48fe-9d3d-9ad331b9ba51@github.com>

On Mon, 20 Jun 2022 09:43:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> Please change the PR title to `Backport 250fbb065a789a303d692d698c9b69117bf6cd2c` and close the manual bug you've created for this backport. The original issue will be used instead once you use the said PR title: https://bugs.openjdk.org/browse/JDK-8049228

@jerboaa PR title has been changed as your advise, but I have no idea about how to close the manual bug JDK-8288718 I created. Could you please provide any suggestions?

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

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

From duke at openjdk.org  Mon Jun 20 12:49:03 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Mon, 20 Jun 2022 12:49:03 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v2]
In-Reply-To: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
Message-ID: <MwTUmDjaouIWCEut9SJX6xTR4Yv3kMO6rScpmteaqaY=.2e1c72e9-0e2b-4eb2-879c-b9299e2d5482@github.com>

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

lusou-zhangquan 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:

  8049228: Improve multithreaded scalability of InetAddress cache
  
  Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/70/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/70/files/799a4f39..5fbde719

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

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

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

From sgehwolf at openjdk.org  Mon Jun 20 13:51:06 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 20 Jun 2022 13:51:06 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache
In-Reply-To: <BkoaoWTNloBcS6LZ-U-cswNJnXufRGHA-gt8P2yn4cs=.9a4061bd-081d-48f5-89e5-4da489c6e369@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <BkoaoWTNloBcS6LZ-U-cswNJnXufRGHA-gt8P2yn4cs=.9a4061bd-081d-48f5-89e5-4da489c6e369@github.com>
Message-ID: <pNBqpU_7lSqT0JkAMr9EeB0yOZOApy5jQuhyzOPobyo=.204580e4-6f0b-4dc4-a31f-29b6a8bf2716@github.com>

On Mon, 20 Jun 2022 09:43:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> Please change the PR title to `Backport 250fbb065a789a303d692d698c9b69117bf6cd2c` and close the manual bug you've created for this backport. The original issue will be used instead once you use the said PR title: https://bugs.openjdk.org/browse/JDK-8049228

> @jerboaa PR title has been changed as your advise, but I have no idea about how to close the manual bug JDK-8288718 I created. Could you please provide any suggestions?

I've closed it as a duplicate for you now.

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

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

From phh at openjdk.org  Mon Jun 20 19:05:46 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 20 Jun 2022 19:05:46 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v2]
In-Reply-To: <MwTUmDjaouIWCEut9SJX6xTR4Yv3kMO6rScpmteaqaY=.2e1c72e9-0e2b-4eb2-879c-b9299e2d5482@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <MwTUmDjaouIWCEut9SJX6xTR4Yv3kMO6rScpmteaqaY=.2e1c72e9-0e2b-4eb2-879c-b9299e2d5482@github.com>
Message-ID: <HmjYgFB8Ydc-bC3Cw22il4G7Zw26Bjbdazfk_Y4szVg=.27508723-99eb-42fe-b603-7e89930c3ae4@github.com>

On Mon, 20 Jun 2022 12:49:03 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan 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:
> 
>   8049228: Improve multithreaded scalability of InetAddress cache
>   
>   Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

Looks fine, but please run at least tier1 tests.

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

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

From duke at openjdk.org  Tue Jun 21 02:27:18 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Tue, 21 Jun 2022 02:27:18 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v3]
In-Reply-To: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
Message-ID: <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>

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

lusou-zhangquan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8049228: Improve multithreaded scalability of InetAddress cache
  
  Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

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

Changes: https://git.openjdk.org/jdk8u-dev/pull/70/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=70&range=02
  Stats: 484 lines in 2 files changed: 133 ins; 235 del; 116 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/70.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/70/head:pull/70

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

From duke at openjdk.org  Tue Jun 21 06:53:48 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Tue, 21 Jun 2022 06:53:48 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache
In-Reply-To: <pNBqpU_7lSqT0JkAMr9EeB0yOZOApy5jQuhyzOPobyo=.204580e4-6f0b-4dc4-a31f-29b6a8bf2716@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <BkoaoWTNloBcS6LZ-U-cswNJnXufRGHA-gt8P2yn4cs=.9a4061bd-081d-48f5-89e5-4da489c6e369@github.com>
 <pNBqpU_7lSqT0JkAMr9EeB0yOZOApy5jQuhyzOPobyo=.204580e4-6f0b-4dc4-a31f-29b6a8bf2716@github.com>
Message-ID: <TA7i5-LL7iHbScsWbn_t3akSbDRXQBRVt7pRcWLVD_4=.b9a8d751-688f-48ac-a5bd-46058282929b@github.com>

On Mon, 20 Jun 2022 13:47:31 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > @jerboaa PR title has been changed as your advise, but I have no idea about how to close the manual bug JDK-8288718 I created. Could you please provide any suggestions?
> 
> I've closed it as a duplicate for you now.

Thanks a lot. Won't make similar mistakes next time.

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

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

From duke at openjdk.org  Tue Jun 21 06:53:50 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Tue, 21 Jun 2022 06:53:50 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v2]
In-Reply-To: <HmjYgFB8Ydc-bC3Cw22il4G7Zw26Bjbdazfk_Y4szVg=.27508723-99eb-42fe-b603-7e89930c3ae4@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <MwTUmDjaouIWCEut9SJX6xTR4Yv3kMO6rScpmteaqaY=.2e1c72e9-0e2b-4eb2-879c-b9299e2d5482@github.com>
 <HmjYgFB8Ydc-bC3Cw22il4G7Zw26Bjbdazfk_Y4szVg=.27508723-99eb-42fe-b603-7e89930c3ae4@github.com>
Message-ID: <15ZzO_rn8i1pxFbSK6ED7vxFG9-3XW8MdDk1mpW5CHA=.692192e9-af44-400a-a40e-9ad3785711fc@github.com>

On Mon, 20 Jun 2022 19:02:03 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> Looks fine, but please run at least tier1 tests.

Re-run the gate and passed. Please take a look again.

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

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

From duke at openjdk.org  Tue Jun 21 08:01:52 2022
From: duke at openjdk.org (George Adams)
Date: Tue, 21 Jun 2022 08:01:52 GMT
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README
Message-ID: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>

Backports https://bugs.openjdk.org/browse/JDK-8251551 as it's a low-risk change and generally improves the readability/usability in GitHub.

Currently, I've just converted the README to markdown format and added a little syntax highlighting. I'm not sure if people would like me to go one step further and rip out the mercurial/nested repo references?

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

Commit messages:
 - Backport 6ed221cb9ad2e81d92dda0ef32095dda5d52cb85

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

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

From phh at openjdk.org  Tue Jun 21 19:04:30 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 21 Jun 2022 19:04:30 GMT
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README
In-Reply-To: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
References: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
Message-ID: <Llj3dh9uhve0q1nSNetNh6yLxUbRFplqjAQcWRxi1DE=.c6dd5a7d-a0cc-4645-90ea-a17f9ec9ae66@github.com>

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

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

Lgtm.

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

Marked as reviewed by phh (Reviewer).

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

From omikhaltcova at openjdk.org  Tue Jun 21 23:18:23 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Tue, 21 Jun 2022 23:18:23 GMT
Subject: [jdk8u-dev] RFR: 8282538: PKCS11 tests fail on CentOS Stream 9
Message-ID: <2CZhV2W69JZ7b4DLOpnbkSjA6Jp8DnG0uWjToNe9Eyo=.c50a6110-2eaf-4e79-aa8b-b4237bf32afe@github.com>

It's backport of JDK-8282538 to jdk8u.
The same failure of the regression tests group (test/jdk/sun/security/pkcs11/Signature/) is observed on CentOS Stream 9 because of missing cert9.db and key4.db which are required by NSS 3.35 and above.
Applied manually due to the location difference:
`test/jdk/sun/security/pkcs11/nss/db/cert9.db`  ->  `jdk/test/sun/security/pkcs11/nss/db/cert9.db`
`test/jdk/sun/security/pkcs11/nss/db/key4.db`  ->  `jdk/test/sun/security/pkcs11/nss/db/key4.db`
Tested manually on CentOS Stream 9 with above mentioned tests group.

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

Commit messages:
 - Backport d8fd22239bafecdaaedb8985ab6d709ed846e808

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

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

From duke at openjdk.org  Wed Jun 22 08:16:17 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Wed, 22 Jun 2022 08:16:17 GMT
Subject: [jdk8u-dev] RFR: 8197859: VS2017 Complains about UINTPTR_MAX
 definition in globalDefinitions_VisCPP.hpp [v2]
In-Reply-To: <MGeIIf-W3hQOM7mbOpSh5zsO2NRca8WgMq7dH4c44V4=.cc25e5ed-7091-475f-8c63-4d9527095c5b@github.com>
References: <MGeIIf-W3hQOM7mbOpSh5zsO2NRca8WgMq7dH4c44V4=.cc25e5ed-7091-475f-8c63-4d9527095c5b@github.com>
Message-ID: <k8fh4Vo1MEB9VgTc6VhqPz1SIHBR1WcYGHJWrezeBCg=.6e2ec06c-9941-49af-b321-2fc3a4475255@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 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://urldefense.com/v3/__https://github.com/openjdk/jdk8u-dev/pull/33__;!!ACWV5N9M2RV99hQ!MQ8en-zp95Ab0GcQhgBtqxWn73nhxKsGF4QzcSCkJYMbwA4ZblsXd-mKU0jZ0DSlukISoS8x3HTfzdsHXks$ )
> 
> Verification: 2019 build (both 32/64) now fails with 
> 
> ad_x86_64_pipeline.obj : error LNK2011: precompiled object not linked in; image may not run
> jvm.dll : fatal error LNK1120: 1 unresolved externals
> 
> error (to be fixed by backport of 8043492)
> 
> Regression: 2017/2013/2012/2010 full build - ok
> 
> @kimbarrett @dholmes-ora if you took a look at that it would be very much appreciated

Alexey Pavlyutkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'backport-8197859' of https://urldefense.com/v3/__https://github.com/apavlyutkin/jdk8u-dev__;!!ACWV5N9M2RV99hQ!MQ8en-zp95Ab0GcQhgBtqxWn73nhxKsGF4QzcSCkJYMbwA4ZblsXd-mKU0jZ0DSlukISoS8x3HTfs1jeYg0$  into backport-8197859
 - fixes trailing whitespaces
 - Backport b8ab854bdcf625772e965a5e476e0a9db1b91f3f
 - fixes trailing whitespaces
 - rebasing and resolving the merge conflict

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

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

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

From duke at openjdk.org  Wed Jun 22 08:18:25 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Wed, 22 Jun 2022 08:18:25 GMT
Subject: [jdk8u-dev] Withdrawn: 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: <2t7Zt2FEbu9j6yNQkOKvncIAQChDYJe4tN36vf7im_E=.9f4e83e6-8203-4436-b328-90005da7e23c@github.com>

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

> Hi! Please review another backport from MSVS2019 seria. This one fixes type declarations made by globalDefinitions_VisCPP.hpp. The patch from 11u applied with the following changes:
> 
> - inttypes.h is included conditionally under `_MSC_VER >= 1800` because the header was introduced only in MSVS 2013 but we have to keep support of the earlier MSVS versions 
> - the duplicates of declarations made in inttypes.h are not just removed but quoted with `_MSC_VER < 1800`
> - common\autoconf\generated-configure.sh is regenerated to add MSVS2019 recognition (I forgot to do that in https://urldefense.com/v3/__https://github.com/openjdk/jdk8u-dev/pull/33__;!!ACWV5N9M2RV99hQ!M4NnegcaHTEzTfkYdO7tglXK_4sQL7AV28eKEAQ-masKtB1LoqriuE8jTzUB-u1YmsfNIucxoKTEDNjdgQc$ )
> 
> 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

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Wed Jun 22 08:43:24 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Wed, 22 Jun 2022 08:43:24 GMT
Subject: [jdk8u-dev] RFR: 8197859: VS2017 Complains about UINTPTR_MAX
 definition in globalDefinitions_VisCPP.hpp
Message-ID: <WCZSnJWqvZqlMsQizOTcP0iaua8g2s4Kk2Ce5mOj6a0=.0b7e5a68-af18-4784-8570-8fdbebff7bdc@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 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://urldefense.com/v3/__https://github.com/openjdk/jdk8u-dev/pull/33__;!!ACWV5N9M2RV99hQ!KzqF3Y6a8VDUdBmbZcBypywsElsSAEli1b_z1imo1BuPr1VNTsCbMoEo4Xk8Y8CMDX0BEV_a28ylJE5IE1E$ )

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:
 - fixing carriage returns
 - Backport b8ab854bdcf625772e965a5e476e0a9db1b91f3f

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

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

From duke at openjdk.org  Wed Jun 22 08:54:19 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Wed, 22 Jun 2022 08:54:19 GMT
Subject: [jdk8u-dev] RFR: 8197859: VS2017 Complains about UINTPTR_MAX
 definition in globalDefinitions_VisCPP.hpp [v2]
In-Reply-To: <WCZSnJWqvZqlMsQizOTcP0iaua8g2s4Kk2Ce5mOj6a0=.0b7e5a68-af18-4784-8570-8fdbebff7bdc@github.com>
References: <WCZSnJWqvZqlMsQizOTcP0iaua8g2s4Kk2Ce5mOj6a0=.0b7e5a68-af18-4784-8570-8fdbebff7bdc@github.com>
Message-ID: <_qTWaz6VjZ7zYsqSTD7biJ9dJn74vQKC3iysr86IJJI=.9f8ea751-56f3-47d8-b169-c0ca071883ab@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 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://urldefense.com/v3/__https://github.com/openjdk/jdk8u-dev/pull/33__;!!ACWV5N9M2RV99hQ!KgCpJhLWf_nWdDCyFcTL0EDwOLL-NJgKY1zrxoJ_TkpCfvWm0j4R0_SNNocvR10HJtbiNvF9nLMGfwhSnPM$ )
> 
> Verification: 2019 build (both 32/64) now fails with 
> 
> ad_x86_64_pipeline.obj : error LNK2011: precompiled object not linked in; image may not run
> jvm.dll : fatal error LNK1120: 1 unresolved externals
> 
> error (to be fixed by backport of 8043492)
> 
> Regression: 2017/2013/2012/2010 full build - ok
> 
> @kimbarrett @dholmes-ora if you took a look at that it would be very much appreciated

Alexey Pavlyutkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge master
 - fixing carriage returns
 - Backport b8ab854bdcf625772e965a5e476e0a9db1b91f3f

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

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

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

From duke at openjdk.org  Thu Jun 23 10:37:03 2022
From: duke at openjdk.org (George Adams)
Date: Thu, 23 Jun 2022 10:37:03 GMT
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README
In-Reply-To: <Llj3dh9uhve0q1nSNetNh6yLxUbRFplqjAQcWRxi1DE=.c6dd5a7d-a0cc-4645-90ea-a17f9ec9ae66@github.com>
References: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
 <Llj3dh9uhve0q1nSNetNh6yLxUbRFplqjAQcWRxi1DE=.c6dd5a7d-a0cc-4645-90ea-a17f9ec9ae66@github.com>
Message-ID: <qBuNgAEGgsfLiQxLpQbQkSp2NuaEA6g-ZWmZUNRhN0s=.c84b80c7-4ee0-45b3-94a1-f2f5d903962d@github.com>

On Tue, 21 Jun 2022 19:02:25 GMT, Paul Hohensee <phh at openjdk.org> wrote:

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

@phohensee can you please ask for integration permission by tagging the JBS issue?

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

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

From gnu.andrew at redhat.com  Fri Jun 24 01:44:08 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 24 Jun 2022 02:44:08 +0100
Subject: OpenJDK 8u342 EA releases
Message-ID: <YrUW6CiAo92ewJZ4@hex.discworld.ac.uk>

I've made available early access source bundles for the 8u342 build
promotions so far:

https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b01-ea.tar.xz
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b02-ea.tar.xz
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b03-ea.tar.xz
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b04-ea.tar.xz
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b05-ea.tar.xz
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b06-ea.tar.xz

The tarballs are accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b01-ea.tar.xz.sig
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b02-ea.tar.xz.sig
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b03-ea.tar.xz.sig
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b04-ea.tar.xz.sig
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b05-ea.tar.xz.sig
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b06-ea.tar.xz.sig

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

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

SHA256 checksums:

0e532fa6d6844fa26e07e91e8763b7535ef45313718ad27b620bf223d964d523  openjdk8u342-b01-ea.tar.xz
ba4b51690b5c0d42bc0633def8b143965daf675feb6c8b5f5f1cf8ae77d052f7  openjdk8u342-b01-ea.tar.xz.sig

b0f514f6d3156fac20da601ef1611d03fceda5e74e56f82b263b710e6369e0fa  openjdk8u342-b02-ea.tar.xz
a22f9ec280f43ab847ae136f3041bc8667d907925e44233f502f760040bd0b2d  openjdk8u342-b02-ea.tar.xz.sig

82bd781a44cf93a2b677418a3e075ad3a5073e3eeeb0b1e8fd106d766bcbff3a  openjdk8u342-b03-ea.tar.xz
4ad3d5aa6f9aeb6471a1c11f95faeca73c140926a00add3d845939b3a719f976  openjdk8u342-b03-ea.tar.xz.sig

5b1f66fff3252b00153f1a6aa4512e1a2d60bc6b513a1c9770ed428544008b77  openjdk8u342-b04-ea.tar.xz
19adedc09a7233c4a3cbe83e1feb47f753972547a90291070736c032de2baacf  openjdk8u342-b04-ea.tar.xz.sig

0ffa33be77a24f3e61ec265fa88ec78613958e728b1e679f8aea49c558048b50  openjdk8u342-b05-ea.tar.xz
21719152ee588e79c42f265b829c9fe272d2e63d9380d4d9746da5fa647801b9  openjdk8u342-b05-ea.tar.xz.sig

a3ddc1507f1fcfdcea921162ac4ef000d158acd80fecd8596ca70f9499239eb1  openjdk8u342-b06-ea.tar.xz
273a8fcc11d019200d28fe88aa716304a2f41f73669cb45c0a6c93b4df6e0433  openjdk8u342-b06-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b01-ea.sha256
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b02-ea.sha256
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b03-ea.sha256
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b04-ea.sha256
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b05-ea.sha256
https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b06-ea.sha256

The tarballs were built on RHEL 6 (x86, x86_64) and RHEL 7 (aarch64,
ppc, ppc64, ppc64le, s390x, x86, x86_64). Note that b04 is known not
to build on AArch64, due to JDK-8284620.  This is fixed in b05.

Note that tomorrow (Friday 2022-06-24) is the last day for changes to
8u342 before the release freeze.

Changes in 8u342-b01:
  - JDK-8076190: Customizing the generation of a PKCS12 keystore
  - JDK-8129572: Cleanup usage of getResourceAsStream in jaxp
  - JDK-8132256: jaxp: Investigate removal of com/sun/org/apache/bcel/internal/util/ClassPath.java
  - JDK-8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream
  - JDK-8194154: System property user.dir should not be changed
  - JDK-8223396: [TESTBUG] several jfr tests do not clean up files created in /tmp
  - JDK-8230865: [TESTBUG] jdk/jfr/event/io/EvilInstrument.java fails at-run shell MakeJAR.sh target
  - JDK-8253424: Add support for running pre-submit testing using GitHub Actions
  - JDK-8253865: Pre-submit testing using GitHub Actions does not detect failures reliably
  - JDK-8254054: Pre-submit testing using GitHub Actions should not use the deprecated set-env command
  - JDK-8254173: Add Zero, Minimal hotspot targets to submit workflow
  - JDK-8254175: Build no-pch configuration in debug mode for submit checks
  - JDK-8254282: Add Linux x86_32 builds to submit workflow
  - JDK-8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale
  - JDK-8255305: Add Linux x86_32 tier1 to submit workflow
  - JDK-8255352: Archive important test outputs in submit workflow
  - JDK-8255373: Submit workflow artifact name is always "test-results_.zip"
  - JDK-8255895: Submit workflow artifacts miss hs_errs/replays due to ZIP include mismatch
  - JDK-8256127: Add cross-compiled foreign architectures builds to submit workflow
  - JDK-8256277: Github Action build on macOS should define OS and Xcode versions
  - JDK-8256354: Github Action build on Windows should define OS and MSVC versions
  - JDK-8256393: Github Actions build on Linux should define OS and GCC versions
  - JDK-8256414: add optimized build to submit workflow
  - JDK-8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing
  - JDK-8257056: Submit workflow should apt-get update to avoid package installation errors
  - JDK-8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386"
  - JDK-8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386"
  - JDK-8261107: ArrayIndexOutOfBoundsException in the ICC_Profile.getInstance(InputStream)
  - JDK-8263667: Avoid running GitHub actions on branches named pr/*
  - JDK-8274658: ISO 4217 Amendment 170 Update
  - JDK-8274751: Drag And Drop hangs on Windows
  - JDK-8279669: test/jdk/com/sun/jdi/TestScaffold.java uses wrong condition
  - JDK-8281814: Debuginfo.diz contains redundant build path after backport JDK-8025936
  - JDK-8282225: GHA: Allow one concurrent run per PR only
  - JDK-8282458: Update .jcheck/conf file for 8u move to git
  - JDK-8282552: Bump update version of OpenJDK: 8u342
  - JDK-8284772: 8u GHA: Use GCC Major Version Dependencies Only
  - JDK-8285445: cannot open file "NUL:"

Changes in 8u342-b02:
  - JDK-8170530: bash configure output contains a typo in a suggested library name
  - JDK-8221988: add possibility to build with Visual Studio 2019
  - JDK-8235211: serviceability/attach/RemovingUnixDomainSocketTest.java fails with AttachNotSupportedException: Unable to open socket file
  - JDK-8244973: serviceability/attach/RemovingUnixDomainSocketTest.java fails "stderr was not empty"

Changes in 8u342-b03:
  - JDK-8168926: C2: Bytecode escape analyzer crashes due to stack overflow
  - JDK-8248876: LoadObject with bad base address created for exec file on linux
  - JDK-8278138: OpenJDK8 fails to start on Windows 8.1 after upgrading compiler to VS2017

Changes in 8u342-b04:
  - JDK-8031567: Better model for storing source revision information
  - JDK-8170385: JDK-8031567 broke source bundles
  - JDK-8170392: JDK-8031567 broke builds from source bundles
  - JDK-8202142: jfr/event/io/TestInstrumentation is unstable
  - JDK-8266187: Memory leak in appendBootClassPath()
  - JDK-8283350: (tz) Update Timezone Data to 2022a
  - JDK-8284620: CodeBuffer may leak _overflow_arena
  - JDK-8285523: Improve test java/io/FileOutputStream/OpenNUL.java
  - JDK-8285727: [11u, 17u] Unify fix for JDK-8284920 with version from head
  - JDK-8286989: Build failure on macOS after 8281814

Changes in 8u342-b05:
  - JDK-8287537: 8u JDK-8284620 backport broke AArch64 build

Changes in 8u342-b06:
  - JDK-8285591: add signum checks in DSA.java engineVerify

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

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

From duke at openjdk.org  Fri Jun 24 06:37:39 2022
From: duke at openjdk.org (ktakakuri)
Date: Fri, 24 Jun 2022 06:37:39 GMT
Subject: [jdk8u-dev] RFR: 8136354: [TEST_BUG] Test
 java/awt/image/RescaleOp/RescaleAlphaTest.java with Bad action for script
Message-ID: <XST-lITtZCk9FIWOQi7f4TbBvlILbVIu4pQfqD7txzg=.d2821f63-5d27-4aae-8d54-d89744a13d8f@github.com>

This is a clean backport of JDK-8136354: [TEST_BUG] Test java/awt/image/RescaleOp/RescaleAlphaTest.java with Bad action for script.
The test passed by applying this backport.

Could you please review this PR?

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

Commit messages:
 - Backport 79d93ad73030

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

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

From andrew at openjdk.org  Fri Jun 24 15:05:56 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 24 Jun 2022 15:05:56 GMT
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README
In-Reply-To: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
References: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
Message-ID: <iYCzzBm4zTXMFRlZ-XKUm_2brjUjJhMssKEBabcrZxA=.52ca9f7d-b725-4dae-befc-91f521331e1c@github.com>

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

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

I think we need to bring in the changes to convert to markdown first (notably [JDK-8139668](https://bugs.openjdk.org/browse/JDK-8139668) and [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509)) before doing this. 

Also, this patch looks to be removing the old file and adding a new one, when it should be a rename. That makes it hard to see what has actually changed.

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

Changes requested by andrew (Reviewer).

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

From duke at openjdk.org  Fri Jun 24 15:10:51 2022
From: duke at openjdk.org (George Adams)
Date: Fri, 24 Jun 2022 15:10:51 GMT
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README
In-Reply-To: <iYCzzBm4zTXMFRlZ-XKUm_2brjUjJhMssKEBabcrZxA=.52ca9f7d-b725-4dae-befc-91f521331e1c@github.com>
References: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
 <iYCzzBm4zTXMFRlZ-XKUm_2brjUjJhMssKEBabcrZxA=.52ca9f7d-b725-4dae-befc-91f521331e1c@github.com>
Message-ID: <qxOk6fKXVpoQSlYry9FCMLZyc9EqpMd-V_np1fIrnzU=.74596e7c-1d53-45de-8b79-841966bd673c@github.com>

On Fri, 24 Jun 2022 15:02:50 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> I think we need to bring in the changes to convert to markdown first (notably [JDK-8139668](https://bugs.openjdk.org/browse/JDK-8139668) and [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509)) before doing this.

I hadn't seen those patches before, are they not focussed on the [README-builds.html](http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html) file rather than the top-level `README` file? I'm not sure why one would block the other.

> Also, this patch looks to be removing the old file and adding a new one, when it should be a rename. That makes it hard to see what has actually changed.

That's the way the patch was applied from the top (see the original [commit](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/6ed221cb9ad2e81d92dda0ef32095dda5d52cb85__;!!ACWV5N9M2RV99hQ!MmYNUhzflNfUpQVY2b6OJEEoTg2nbR6f4kN4TElpLorFx2Zl2yF-06MhoTZPLO0PQNKdHWUyViLpZiGzUvY$ )). I wouldn't like to change that now as it would be inconsistent with the other repos?

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

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

From andrew at openjdk.org  Fri Jun 24 16:26:57 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 24 Jun 2022 16:26:57 GMT
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README
In-Reply-To: <qxOk6fKXVpoQSlYry9FCMLZyc9EqpMd-V_np1fIrnzU=.74596e7c-1d53-45de-8b79-841966bd673c@github.com>
References: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
 <iYCzzBm4zTXMFRlZ-XKUm_2brjUjJhMssKEBabcrZxA=.52ca9f7d-b725-4dae-befc-91f521331e1c@github.com>
 <qxOk6fKXVpoQSlYry9FCMLZyc9EqpMd-V_np1fIrnzU=.74596e7c-1d53-45de-8b79-841966bd673c@github.com>
Message-ID: <n6C0HBkG4pdRgPy2lk3pMHMmpnXLLG_rJzJh4yM79ws=.7242bfec-d736-4490-afe9-80ff024f154b@github.com>

On Fri, 24 Jun 2022 15:07:14 GMT, George Adams <duke at openjdk.org> wrote:

> > I think we need to bring in the changes to convert to markdown first (notably [JDK-8139668](https://bugs.openjdk.org/browse/JDK-8139668) and [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509)) before doing this.
> 
> I hadn't seen those patches before, are they not focussed on the [README-builds.html](http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html) file rather than the top-level `README` file? I'm not sure why one would block the other.
> 

8176509 also updates README and would essentially making this patch a clean backport as far as I can see. If we apply this change first as it is, we'll introduce changes unique to 8u into the README file. 8139668 is a prerequisite for 8176509.

> > Also, this patch looks to be removing the old file and adding a new one, when it should be a rename. That makes it hard to see what has actually changed.
> 
> That's the way the patch was applied from the top (see the original [commit](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/6ed221cb9ad2e81d92dda0ef32095dda5d52cb85__;!!ACWV5N9M2RV99hQ!Mx5kWBOIf8yFiVO9fsFpB4WaIfmYjzYZyL6m5drK1ThpvGfLoLS3QjG1xlHKopYlYTFsPszF2X2Q5Rda_LRbzA$ )). I wouldn't like to change that now as it would be inconsistent with the other repos?

Ugh, I see. Well, we're already inconsistent with other repos with this patch, because the file being changed is quite different. Not having this as a rename makes it hard to see what changes have been made other than the rename.

I can accept the patch as it is in trunk and 11u if we're doing the same change on top of JDK-8176509. If we're going to do unique 8u changes, we should do the rename properly.

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

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

From t.glaser at tarent.de  Fri Jun 24 17:13:07 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Fri, 24 Jun 2022 19:13:07 +0200 (CEST)
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for
 README
In-Reply-To: <n6C0HBkG4pdRgPy2lk3pMHMmpnXLLG_rJzJh4yM79ws=.7242bfec-d736-4490-afe9-80ff024f154b@github.com>
References: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
 <iYCzzBm4zTXMFRlZ-XKUm_2brjUjJhMssKEBabcrZxA=.52ca9f7d-b725-4dae-befc-91f521331e1c@github.com>
 <qxOk6fKXVpoQSlYry9FCMLZyc9EqpMd-V_np1fIrnzU=.74596e7c-1d53-45de-8b79-841966bd673c@github.com>
 <n6C0HBkG4pdRgPy2lk3pMHMmpnXLLG_rJzJh4yM79ws=.7242bfec-d736-4490-afe9-80ff024f154b@github.com>
Message-ID: <ac2dcae-a795-9db1-186d-edd3373322c@tarent.de>

On Fri, 24 Jun 2022, Andrew John Hughes wrote:

> Not having this as a rename makes it hard to see what changes have
> been made other than the rename.

In git, merely the content is stored. The decision of whether to
render a change as diff or removal+addition (or copy+diff) lies
with the client invoking the diff (log -p, ?) command and is done
every time anew.

You might have luck using git diff -M40% or even smaller numbers.

HTH & HAND,
//mirabilos

PS: This is one of the reasons git is not a version control system.
    Torvalds himself calls it a ?stupid content tracker?.
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? https://urldefense.com/v3/__http://www.tarent.de/__;!!ACWV5N9M2RV99hQ!PJdFeXULUrQ0KWYVpN2vPkrH8ux0JTIQhQ3s4kJOlopQWTlHHRpZRNmBLNI20PvO-uvll9VNdMbJj8RYy09vgq8$ 
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://urldefense.com/v3/__https://www.tarent.de/newsletter__;!!ACWV5N9M2RV99hQ!PJdFeXULUrQ0KWYVpN2vPkrH8ux0JTIQhQ3s4kJOlopQWTlHHRpZRNmBLNI20PvO-uvll9VNdMbJj8RYqpN61Wo$ 
??? header encryption!
                        ****************************************************

From andrew at openjdk.org  Fri Jun 24 17:27:52 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 24 Jun 2022 17:27:52 GMT
Subject: [jdk8u-dev] RFR: 8087283: Add support for the XML Signature here()
 function to the JDK XPath implementation [v3]
In-Reply-To: <ol0D5SMRWEygds_D2tvxFRgpLCoDYOSd8EJwEjRhj2Q=.bc5b98ae-1c69-436f-81a5-2290dd10f0f9@github.com>
References: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
 <ol0D5SMRWEygds_D2tvxFRgpLCoDYOSd8EJwEjRhj2Q=.bc5b98ae-1c69-436f-81a5-2290dd10f0f9@github.com>
Message-ID: <ejjk7qAV5kdr9w2nNCZRCvGm64mQ-0ky7_j5A0qpy6Q=.f1f785f5-2b8c-4ee3-83a8-60fa5df1c84f@github.com>

On Thu, 2 Jun 2022 07:08:26 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

>> 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.
>
> Yuri Nesterenko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make Keywords.java a copy of 11u state

Approved.

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

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

From andrew at openjdk.org  Fri Jun 24 17:39:04 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 24 Jun 2022 17:39:04 GMT
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README
In-Reply-To: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
References: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
Message-ID: <W0JyblcUvnhtSdOZ1yThJd1jrYRTAx0-HHG7Q3tWHxo=.18161227-3dbc-4bcf-968d-65f576c4281f@github.com>

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

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

I've opened #79 for the first of these. Once both are in, you should be able to just do this change cleanly.

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

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

From andrew at openjdk.org  Fri Jun 24 17:44:28 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 24 Jun 2022 17:44:28 GMT
Subject: [jdk8u-dev] RFR: 8139668: Generate README-build.html from markdown
Message-ID: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>

This updates the build documentation so it `README-builds.html` is generated from `README-builds,md`

This is a precursor to [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509) which also updates the `README`, simplifying #75 

There are deliberately no content changes here. In fact, JDK 9 changes to the documentation prior to this change are reverted (VS2010->VS2013 bump and other build requirement changes (namely [JDK-8041593](https://bugs.openjdk.org/browse/JDK-8041593) (JDK9 update), [JDK-8062223](https://bugs.openjdk.org/browse/JDK-8062223) (ccache update), [JDK-8076531](https://bugs.openjdk.org/browse/JDK-8076531) (Windows default compiler change) and [JDK-8072023](https://bugs.openjdk.org/browse/JDK-8072023) (make version change)). We can make our own updates once these changes are in.

The updated `README-builds.html` was generated from the new `README-builds.md`. I fixed a bug in `common/bin/update-build-readme.sh` which checks the variable `MARKDOWN` for the location of the processor but then uses a bare `markdown` in the actual invocation.  This script is removed in JDK-8176509 anyway, being replaced with `pandoc`.

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

Commit messages:
 - Backport 17c896827dbf1a54ab6539cc2b506f973dbde246

Changes: https://git.openjdk.org/jdk8u-dev/pull/79/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=79&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8139668
  Stats: 4159 lines in 3 files changed: 1667 ins; 1445 del; 1047 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/79.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/79/head:pull/79

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

From serb at openjdk.org  Fri Jun 24 18:26:57 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 24 Jun 2022 18:26:57 GMT
Subject: [jdk8u-dev] RFR: 8139668: Generate README-build.html from markdown
In-Reply-To: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
References: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
Message-ID: <86I2-vbk6aoBUlr6Y8A8XNrz_9QnhM2ecBXFIjPCm7U=.0d28efc4-f443-49b3-bb20-07730ac6d8eb@github.com>

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

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

Probably we should move this document to the new doc folder? Do we have a plans to align Readme/BuildDoc to the jdk/jdk version, simple readme with a few links and other docs in "doc" folder?: https://urldefense.com/v3/__https://github.com/openjdk/jdk__;!!ACWV5N9M2RV99hQ!MgDRDMzTYEPGYgxcsEe8WaXc2x0JlksBSF3hzD9X3HLlfv1G14eXWp8X1UQOZDrM866hHQ9XBLyFkr06KtY$ 

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

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

From serb at openjdk.org  Mon Jun 27 04:17:18 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Jun 2022 04:17:18 GMT
Subject: [jdk8u-dev] RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled
Message-ID: <ImYzQRJ5mteFVjl4P0piwd0_GTLWZBNXegC-CM9YPGw=.476a9301-d6fe-4821-ae6a-144a00a2015a@github.com>

Hi all,
This pull request contains a backport of commit [50d47de8](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/50d47de8358e2f22bf3a4a165d660c25ef6eacbc__;!!ACWV5N9M2RV99hQ!K6Qz_B8yfPZheXw0dqmz8NK_5XIbEeE-pra91MELIt6RK5cLYhANfYMRZ0TwAc96zcfFIje56psRZSijPgU$ ) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Jaikiran Pai on 12 May 2022 and was reviewed by Magnus Ihse Bursie and Lance Andersen.

The patch for JDK8 is slightly different:
 * The main code patch is moved from the `make/autoconf/lib-bundled.m4` to the `jdk/make/lib/CoreLibraries.gmk` the same place where `":= -lz"` option is set.
 * All disabled warnings are removed from the patch, seems we do not have such DISABLED_WARNINGS_XX in JDK8

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

Commit messages:
 - Simplify the change
 - Merge branch 'master' into JDK-8286582
 - 8286582: Build fails on macos aarch64 when using --with-zlib=bundled

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

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

From duke at openjdk.org  Mon Jun 27 12:30:13 2022
From: duke at openjdk.org (Long Yang)
Date: Mon, 27 Jun 2022 12:30:13 GMT
Subject: [jdk8u-dev] Integrated: 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: <D6qzS_E6KfGBEH6bzzB7S2Xev9sVAy-DqaOmIGQ0zgs=.e8fbd9de-2308-40c9-a835-03e0923d3bd9@github.com>

On Mon, 18 Apr 2022 04:09:21 GMT, Long Yang <duke at openjdk.org> 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://urldefense.com/v3/__https://github.com/openjdk/jdk11u-dev/commit/1d204c554ffe969567161cc05992486ff47d346d__;!!ACWV5N9M2RV99hQ!PTNDNigiV8MGBwnkg5SELrxI7eKg7Qy6Yyvtx5Uw7NfxxfJXj6HkfMAhAUVn3_qNlo0Uwjy1hYp6uSXeMEE$ 
> 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

This pull request has now been integrated.

Changeset: cf6b6282
Author:    yibo.yl <yibo.yl at alibaba-inc.com>
Committer: Denghui Dong <ddong at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/cf6b6282c4836e561e88a114a8d72db4180b160c
Stats:     230 lines in 6 files changed: 219 ins; 8 del; 3 mod

8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)

Reviewed-by: zgu
Backport-of: a9d2267f8d306522522c999ff584ccaa34c46456

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

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

From serb at openjdk.org  Tue Jun 28 06:34:30 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Jun 2022 06:34:30 GMT
Subject: [jdk8u-dev] RFR: 8288928: Incorrect GPL header in pnglibconf.h
Message-ID: <D065rv5snIRUcBwqsgwlMn7e46MI1rP2BA_f80wBhmo=.3c96e402-5f11-4403-a792-d65497ad2b66@github.com>

Hi all,
This pull request contains a backport of commit [70762d39](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/70762d397267f85ce81727ec0c89c9448967798e__;!!ACWV5N9M2RV99hQ!PcsrE9fxqPtBxcRqRYw5sQxEVF173WStlih-v-8ymXAv58S3FsR8u-nX4wo0-qLqxuDCVL4gBPG2rB8OtSg$ ) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Sergey Bylokhov on 7 Oct 2019 and was reviewed by Phil Race.
Thanks!

Backport is clean, but I have to create a new JBS issue, the initial one is closed.

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

Commit messages:
 - Backport 70762d397267f85ce81727ec0c89c9448967798e

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

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

From andrew at openjdk.org  Tue Jun 28 13:44:45 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 28 Jun 2022 13:44: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: <Pa9MDiKD1CnPZz0FZ75_irTEkReRS55rX4NEHv6l9IM=.a818076c-2321-472b-b195-fc2af61c9184@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

I've approved the bug with `jdk8u-fix-yes` and can sponsor once you integrate.

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

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

From phh at openjdk.org  Tue Jun 28 16:51:51 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 28 Jun 2022 16:51:51 GMT
Subject: [jdk8u-dev] RFR: 8288928: Incorrect GPL header in pnglibconf.h
In-Reply-To: <D065rv5snIRUcBwqsgwlMn7e46MI1rP2BA_f80wBhmo=.3c96e402-5f11-4403-a792-d65497ad2b66@github.com>
References: <D065rv5snIRUcBwqsgwlMn7e46MI1rP2BA_f80wBhmo=.3c96e402-5f11-4403-a792-d65497ad2b66@github.com>
Message-ID: <w8n9E6OLaoDWU-h4TgVuphs-RqqDfZM4L6vI3roUlvY=.9449eec6-e690-4df4-8877-29a086e885e7@github.com>

On Tue, 28 Jun 2022 05:53:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [70762d39](https://github.com/openjdk/jdk/commit/70762d397267f85ce81727ec0c89c9448967798e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Sergey Bylokhov on 7 Oct 2019 and was reviewed by Phil Race.
> Thanks!
> 
> Backport is clean, but I have to create a new JBS issue, the initial one is closed.

Lgtm.

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

Marked as reviewed by phh (Reviewer).

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

From andrew at openjdk.org  Tue Jun 28 16:51:50 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 28 Jun 2022 16:51:50 GMT
Subject: [jdk8u-dev] RFR: 8285802: AArch64: Consistently handle offsets in
 MacroAssembler as 64-bit quantities
In-Reply-To: <VCRzjYfm13UtDEi_sMpZ7wlbOWUy7lhxQ2msR8jFndw=.2a0460bd-1a9b-4590-bf1d-7ff3944f2ba5@github.com>
References: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>
 <VCRzjYfm13UtDEi_sMpZ7wlbOWUy7lhxQ2msR8jFndw=.2a0460bd-1a9b-4590-bf1d-7ff3944f2ba5@github.com>
Message-ID: <EM-hFNIDHwt9MTacX2YL6NsxLKBC7HtilWncICC6Qgw=.d2839817-f522-44eb-8633-9897e3bb7d10@github.com>

On Mon, 2 May 2022 09:09:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I'm going to have to do some more work on this one.
> 
> Is there something we can do to make testing work automatically?

The PR should at least do builds on Linux x86, Linux x86_64, Windows and Mac once GitHub Actions are turned on. To run the JTreg tests and produce cross-compiled builds, we need to be able to pass the built JDK from one stage to another, which requires backporting bundles or some alternative I'll try and look that again after the July update is out of the way.

It won't really help on AArch64 though, as I don't believe there's any AArch64 hardware on Gitlab. So the most we can do is cross-compile for AArch64.

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

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

From andrew at openjdk.org  Tue Jun 28 16:51:53 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 28 Jun 2022 16:51:53 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: <H_7VkR7T01rxzuWhuELMkrNOKzS6qDdaVKAMeK0R07E=.fb3ceb8b-b980-4691-9ff2-7f011ac9f9b7@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 take this should now be replaced by https://bugs.openjdk.org/browse/JDK-8285923 ?

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

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

From phh at openjdk.org  Tue Jun 28 16:56:44 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 28 Jun 2022 16:56:44 GMT
Subject: [jdk8u-dev] RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled
In-Reply-To: <ImYzQRJ5mteFVjl4P0piwd0_GTLWZBNXegC-CM9YPGw=.476a9301-d6fe-4821-ae6a-144a00a2015a@github.com>
References: <ImYzQRJ5mteFVjl4P0piwd0_GTLWZBNXegC-CM9YPGw=.476a9301-d6fe-4821-ae6a-144a00a2015a@github.com>
Message-ID: <unF1ZeLoivKLpfiv9jZd21CYybhCwZbA7_qh85B5z7Y=.448ba72d-34c5-42c9-ba9a-c94c41703a50@github.com>

On Mon, 27 Jun 2022 00:33:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [50d47de8](https://github.com/openjdk/jdk/commit/50d47de8358e2f22bf3a4a165d660c25ef6eacbc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Jaikiran Pai on 12 May 2022 and was reviewed by Magnus Ihse Bursie and Lance Andersen.
> 
> The patch for JDK8 is slightly different:
>  * The main code patch is moved from the `make/autoconf/lib-bundled.m4` to the `jdk/make/lib/CoreLibraries.gmk` the same place where `":= -lz"` option is set.
>  * All disabled warnings are removed from the patch, seems we do not have such DISABLED_WARNINGS_XX in JDK8

Lgtm.

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

Marked as reviewed by phh (Reviewer).

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

From phh at openjdk.org  Tue Jun 28 17:01:53 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 28 Jun 2022 17:01:53 GMT
Subject: [jdk8u-dev] RFR: 8136354: [TEST_BUG] Test
 java/awt/image/RescaleOp/RescaleAlphaTest.java with Bad action for script
In-Reply-To: <XST-lITtZCk9FIWOQi7f4TbBvlILbVIu4pQfqD7txzg=.d2821f63-5d27-4aae-8d54-d89744a13d8f@github.com>
References: <XST-lITtZCk9FIWOQi7f4TbBvlILbVIu4pQfqD7txzg=.d2821f63-5d27-4aae-8d54-d89744a13d8f@github.com>
Message-ID: <M9UalRYFAmOX8w-E6cUG6xb_8dRJY7ZzNhh66IepIEo=.c93f51a4-cc07-4736-8005-1bcc1ceeaf9f@github.com>

On Thu, 23 Jun 2022 06:29:57 GMT, ktakakuri <duke at openjdk.org> wrote:

> This is a clean backport of JDK-8136354: [TEST_BUG] Test java/awt/image/RescaleOp/RescaleAlphaTest.java with Bad action for script.
> The test passed by applying this backport.
> 
> Could you please review this PR?

This is a clean backport, so doesn't require explicit review. Just tag and comment on the JBS issue.

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

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

From gnu.andrew at redhat.com  Wed Jun 29 01:15:19 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 29 Jun 2022 02:15:19 +0100
Subject: [FREEZE] 8u342 NOW FROZEN
Message-ID: <YrunpwEClymnVqAW@rincewind>

The release tree:

https://github.com/openjdk/jdk8u

is now frozen in preparation for release on or after 2022-07-19.

The final pre-release tag will be jdk8u342-b06.

The final release tag will be no lower than jdk8u342-b07.
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

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

From aph at openjdk.org  Wed Jun 29 08:49:47 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 29 Jun 2022 08:49:47 GMT
Subject: [jdk8u-dev] RFR: 8285802: AArch64: Consistently handle offsets in
 MacroAssembler as 64-bit quantities
In-Reply-To: <H_7VkR7T01rxzuWhuELMkrNOKzS6qDdaVKAMeK0R07E=.fb3ceb8b-b980-4691-9ff2-7f011ac9f9b7@github.com>
References: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>
 <H_7VkR7T01rxzuWhuELMkrNOKzS6qDdaVKAMeK0R07E=.fb3ceb8b-b980-4691-9ff2-7f011ac9f9b7@github.com>
Message-ID: <srSJb4PGa-IkANeqDg-sNNw5Te4peY50RSE5UtKqIOc=.22437ad1-0bc5-4443-864f-cf2012d3a773@github.com>

On Tue, 28 Jun 2022 16:48:41 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> I take this should now be replaced by https://bugs.openjdk.org/browse/JDK-8285923 ?

Possibly not. Mainline has changed a great deal, so backporting becomes very tricky and involves a bunch of other changes if it is to be stable. At minimum, there were additional patches. Unless this is seriously biting people on 8 I wouldn't.

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

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

From dongbohe at openjdk.org  Wed Jun 29 16:34:49 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Wed, 29 Jun 2022 16:34:49 GMT
Subject: [jdk8u-dev] Integrated: 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: <mBIIOhQD7VKuTuzA8NnF68_Vuea-T8SjyZEDmYcqg_o=.c5e40310-ef0f-48c4-a3dd-6357a795ccc1@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 pull request has now been integrated.

Changeset: 1b4f32d6
Author:    Dongbo He <dongbohe at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/1b4f32d61e3b0460c82598f24dbd5c4dd0fc3bbe
Stats:     98 lines in 8 files changed: 69 ins; 6 del; 23 mod

8173361: various crashes in JvmtiExport::post_compiled_method_load

Don't post information that uses metadata from unloaded nmethods

Reviewed-by: andrew, sspitsyn
Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241

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

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

From andrew at openjdk.org  Wed Jun 29 16:40:50 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 29 Jun 2022 16:40:50 GMT
Subject: [jdk8u-dev] RFR: 8235218: Minimal VM is broken after JDK-8173361
 [v2]
In-Reply-To: <j_AxGhcYEsf2Lg1fC44xMONuYkrsRNNNE1lIRfCuWwY=.dcd8ecd1-9f53-4092-951c-bcb92791db08@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
 <j_AxGhcYEsf2Lg1fC44xMONuYkrsRNNNE1lIRfCuWwY=.dcd8ecd1-9f53-4092-951c-bcb92791db08@github.com>
Message-ID: <CHMC3GAJlHCCl1V1Fo_FLWKJ7E6HmkHm3niVNluVJJw=.d0703b83-58b7-4463-97e4-5bd50fba33d4@github.com>

On Mon, 30 May 2022 01:36:51 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
>
> 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

The target of this PR seems wrong. It should be 8u/master not 8u/pr/9. Maybe easier to start fresh?

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

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

From dongbohe at openjdk.org  Thu Jun 30 03:26:33 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Thu, 30 Jun 2022 03:26:33 GMT
Subject: [jdk8u-dev] RFR: 8235218: Minimal VM is broken after JDK-8173361
 [v3]
In-Reply-To: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
Message-ID: <1y_wu-EgA43QwzyZ-LGb35mygX2OOKC8jUjTxmgIqhI=.6b844676-e90d-405e-b4be-29fa383a1ef1@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 four additional commits since the last revision:

 - Merge master
 - Merge branch 'master' into 8235218
 - Backport c10f731b11f314c97660df08c62f3c3d2f718f54
 - 8173361: various crashes in JvmtiExport::post_compiled_method_load
   
   Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/19/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/19/files/c12d8390..cc2d6785

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

  Stats: 979 lines in 13 files changed: 897 ins; 45 del; 37 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/19.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/19/head:pull/19

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

From dongbohe at openjdk.org  Thu Jun 30 03:26:35 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Thu, 30 Jun 2022 03:26:35 GMT
Subject: [jdk8u-dev] RFR: 8235218: Minimal VM is broken after JDK-8173361
 [v2]
In-Reply-To: <j_AxGhcYEsf2Lg1fC44xMONuYkrsRNNNE1lIRfCuWwY=.dcd8ecd1-9f53-4092-951c-bcb92791db08@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
 <j_AxGhcYEsf2Lg1fC44xMONuYkrsRNNNE1lIRfCuWwY=.dcd8ecd1-9f53-4092-951c-bcb92791db08@github.com>
Message-ID: <6QHNbNiAySEuXw1GnU19zjLRkEoY7Kzk2g0guzMFfy4=.dd6dce8f-4058-4e80-83b0-712ec860e281@github.com>

On Mon, 30 May 2022 01:36:51 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
>
> 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

According to the description of [New Skara feature: dependent pull requests](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html), we need to target to pr/9.

It seems that I need to merge master, I will try.

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

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

From dongbohe at openjdk.org  Thu Jun 30 03:34:39 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Thu, 30 Jun 2022 03:34:39 GMT
Subject: [jdk8u-dev] RFR: 8173339: AArch64: Fix minimum stack size
 computations [v2]
In-Reply-To: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
References: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
Message-ID: <4W0R9iGGasm7Hh6CiOuLR7wV6nVQstafZzabvhThm-s=.74ddc7a6-3d2e-4e57-8d37-82d150a8ece4@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: Performed full jtreg test aarch64-linux-gnu platforms with 4k page size.
> Following test case worked correctly after patch.
> Before patch:
> $ java TLSStackOverflow
> [1]    35476 segmentation fault (core dumped) java TLSStackOverflow
> After patch:
> $ java TLSStackOverflow
> got expected stackoverflow, passed
> 
> $ keytool -genkey -keyalg RSA -keystore localhost-rsa.jks -storepass changeit -storetype pkcs12
> $ cat TLSStackOverflow.java
> 
> import javax.net.ServerSocketFactory;
> import javax.net.SocketFactory;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.net.Socket;
> import java.security.KeyStore;
> import java.security.KeyStoreException;
> import java.security.NoSuchAlgorithmException;
> import java.security.SecureRandom;
> import java.security.cert.CertificateException;
> import java.security.cert.X509Certificate;
> 
> public class TLSStackOverflow
> {
> 
>     private static final String keystore = "/home/hedongbo/myprojects/study/stackoverflow/new/localhost-rsa.jks";
>     private static final char[] passphrase = "changeit".toCharArray();
>     private static final int port = 8447;
> 
>     private static KeyStore pfx = null;
> 
>     public static void doWrite(OutputStream out) throws Exception {
>         out.write("hello".getBytes(), 0, 3);
>         out.flush();
>         doWrite(out);
>     }
> 
>     public TLSStackOverflow()
>     {}
> 
>     public static void main(String[] args) throws Exception
>     {
>         new Thread(() -> {
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 KeyManager[] kms = kmf.getKeyManagers();
>                 ctx.init(kms, null, null);
>                 ServerSocketFactory fact = ctx.getServerSocketFactory();
>                 SSLServerSocket serversocket = (SSLServerSocket) fact.createServerSocket(port);
>                 while (true)
>                 {
>                     Socket socket = null;
>                     try
>                     {
>                         socket = serversocket.accept();
> 
>                         DataInputStream in = new DataInputStream(socket.getInputStream());
>                         DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                         byte[] buf = new byte[8192];
>                         int len = in.read(buf);
>                     }
>                     catch (Exception e)
>                     {
>                         e.printStackTrace();
>                     }
>                     finally
>                     {
> //                        try
> //                        {
> //                            socket.close();
> //                        }
> //                        catch (Exception e) {
> //                            e.printStackTrace();
> //                        }
>                     }
>                 }
>             } catch (Exception e) {
>                 e.printStackTrace();
>             }
>         }).start();
> 
>         Thread.sleep(2000);
> 
>         new Thread(() -> {
>             SSLSocket socket = null;
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 TrustAllManager[] trust = { new TrustAllManager() };
>                 ctx.init(null, trust, null);
>                 SocketFactory fact = ctx.getSocketFactory();
>                 socket = (SSLSocket) fact.createSocket();
>                 socket.connect(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 2000);
>                 socket.setTcpNoDelay(true);
>                 socket.startHandshake();
> 
>                 DataInputStream in = new DataInputStream(socket.getInputStream());
>                 DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                 String s = "GET " + " HTTP/1.1\r\n";
>                 s+= "Accept: */*\r\n";
>                 s+= "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)\r\n";
>                 s+= "Connection: Close\r\n";
>                 s+= "\r\n";
>                 try {
>                     doWrite(out);
>                 } catch (StackOverflowError e) {
>                     System.out.println("got expected stackoverflow, passed");
>                     System.exit(0);
>                 }
> 
>                 byte[] buf = new byte[8192];
>                 int len = in.read(buf);
>                 if (len == -1)
>                 {
>                     System.out.println("eof");
>                     return;
>                 }
>                 System.out.println(new String(buf, 0, len));
>             }
>             catch (Exception e)
>             {
>                 e.printStackTrace();
>             }
>             finally
>             {
>                 try
>                 {
>                     socket.close();
>                 }
>                 catch (Exception e)
>                 {}
>             }
> 
>         }).start();
> 
>     }
> 
> }
> 
> 
> class TrustAllManager implements X509TrustManager
> {
>     private X509Certificate[] issuers;
> 
>     public TrustAllManager()
>     {
>         this.issuers = new X509Certificate[0];
>     }
> 
>     public X509Certificate[] getAcceptedIssuers()
>     {
>         return issuers ;
>     }
> 
>     public void checkClientTrusted(X509Certificate[] chain, String authType)
>     {}
> 
>     public void checkServerTrusted(X509Certificate[] chain, String authType)
>     {}
> }

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

 - Merge branch 'master' into 8173339
 - Backport 540ec375c30e973ceb1a944d5cc60cc8532e88ec

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/66/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/66/files/81b2f750..881b06f7

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

  Stats: 1077 lines in 21 files changed: 966 ins; 51 del; 60 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/66.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/66/head:pull/66

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

From dongbohe at openjdk.org  Thu Jun 30 03:36:49 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Thu, 30 Jun 2022 03:36:49 GMT
Subject: [jdk8u-dev] RFR: 8067941: [TESTBUG] Fix tests for OS with 64K page
 size. [v2]
In-Reply-To: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>
References: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>
Message-ID: <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>

> Hi,
> 
> I would like to backport this patch to fix tests for OS with 64K page size.
> Patch does not apply cleanly: 
> JDK-8062854[1] move StackOverflowBug.java and Test8009761.java to corresponding subfolders.
> Test8009761.java context is different because JDK-8021775[2] and JDK-8011397[3] doesn't in jdk8u.
> Change to TestGCLogMessages.java is excluded because it was added in JDK-8027962[4].
> Chnage to WBStackSize.java is excluded because JDK-8032970[5] does not exist in 8.
> 
> I changed Xss in StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java, 
> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java and TestStackBangRbp.java from
> 392k to 512k according to JDK-8159335[6], because JDK-8173339[7] changed StackShadowPages to 20, xss needs at least 456k.
> 
> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 64k page size.
> Checked that StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java,
> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java, TestStackBangRbp.java,
> TestHumongousAllocInitialMark.java, TestCMSHeapSizeFlags.java, TestG1HeapSizeFlags.java,
> TestParallelHeapSizeFlags.java, TestSerialHeapSizeFlags.java fails without the patch
> and passes with the patch on Aarch64 with 64K page size.
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8062854
> [2] https://bugs.openjdk.java.net/browse/JDK-8021775
> [3] https://bugs.openjdk.java.net/browse/JDK-8011397
> [4] https://bugs.openjdk.java.net/browse/JDK-8027962
> [5] https://bugs.openjdk.java.net/browse/JDK-8032970
> [6] https://bugs.openjdk.java.net/browse/JDK-8159335
> [7] https://bugs.openjdk.java.net/browse/JDK-8173339

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

 - Merge branch '8173339' into 8067941
 - Backport 8e2df5f543522866e7c27ff95ea6fb6458393682

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/71/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/71/files/b2717683..565302ee

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

  Stats: 1077 lines in 21 files changed: 966 ins; 51 del; 60 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/71.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/71/head:pull/71

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

From dongbohe at openjdk.org  Thu Jun 30 04:48:32 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Thu, 30 Jun 2022 04:48:32 GMT
Subject: [jdk8u-dev] RFR: 8235218: Minimal VM is broken after JDK-8173361
 [v3]
In-Reply-To: <1y_wu-EgA43QwzyZ-LGb35mygX2OOKC8jUjTxmgIqhI=.6b844676-e90d-405e-b4be-29fa383a1ef1@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
 <1y_wu-EgA43QwzyZ-LGb35mygX2OOKC8jUjTxmgIqhI=.6b844676-e90d-405e-b4be-29fa383a1ef1@github.com>
Message-ID: <zjUciGYYgb1GCizDP3svv6iLeLZhrykAZiThMIT3EZ0=.f0eb3fd8-62cf-4019-809c-76ca252cd8c4@github.com>

On Thu, 30 Jun 2022 03:26:33 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
>
> 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 four additional commits since the last revision:
> 
>  - Merge master
>  - Merge branch 'master' into 8235218
>  - Backport c10f731b11f314c97660df08c62f3c3d2f718f54
>  - 8173361: various crashes in JvmtiExport::post_compiled_method_load
>    
>    Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241

It looks ok.

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

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

From duke at openjdk.org  Thu Jun 30 08:58:44 2022
From: duke at openjdk.org (George Adams)
Date: Thu, 30 Jun 2022 08:58:44 GMT
Subject: [jdk8u-dev] RFR: 8139668: Generate README-build.html from markdown
In-Reply-To: <86I2-vbk6aoBUlr6Y8A8XNrz_9QnhM2ecBXFIjPCm7U=.0d28efc4-f443-49b3-bb20-07730ac6d8eb@github.com>
References: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
 <86I2-vbk6aoBUlr6Y8A8XNrz_9QnhM2ecBXFIjPCm7U=.0d28efc4-f443-49b3-bb20-07730ac6d8eb@github.com>
Message-ID: <QP0oUNxdxjq42KRy8C7YQ8r1G_JGcs2lLdi-j8WULww=.7629b303-7ab6-4c5c-95f3-29cc15d695ad@github.com>

On Fri, 24 Jun 2022 18:23:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Probably we should move this document to the new doc folder? Do we have a plans to align Readme/BuildDoc to the jdk/jdk version, simple readme with a few links and other docs in "doc" folder?: https://github.com/openjdk/jdk

It's unclear when the move to the `doc` folder happened, reading a few issues it looks like it happened as part of the consilidation into a mono repo. It possibly should have happened when the JDK8u repo was converted into a mono repo. @gnu-andrew I feel this backport is likely the best place to create the `docs` directory.

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

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

From yan at openjdk.org  Thu Jun 30 11:14:53 2022
From: yan at openjdk.org (Yuri Nesterenko)
Date: Thu, 30 Jun 2022 11:14:53 GMT
Subject: [jdk8u-dev] Integrated: 8087283: Add support for the XML Signature
 here() function to the JDK XPath implementation
In-Reply-To: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
References: <tyFzdUwJFU20EYU9JWD_yT1gFPU0uHAFAhNyKEta0Wo=.63edbce3-e2cc-4914-aa80-186916277fe8@github.com>
Message-ID: <O1eCN1lH8iato2xBy6geFb6cKLAuCV3JiIj4aqOb0lg=.bce03e98-5799-4544-b7a8-d3ab4d28ff8e@github.com>

On Mon, 30 May 2022 12:11:43 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> 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.

This pull request has now been integrated.

Changeset: a3c0ed26
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/a3c0ed269c37879c4763f2a58b5d469b7797e3c3
Stats:     157 lines in 4 files changed: 129 ins; 1 del; 27 mod

8087283: Add support for the XML Signature here() function to the JDK XPath implementation

Reviewed-by: andrew
Backport-of: 22fad64529a890dd3ae8b07c7981d9a720cf8e96

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

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

From andrew at openjdk.org  Thu Jun 30 14:03:30 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 30 Jun 2022 14:03:30 GMT
Subject: [jdk8u-dev] RFR: 8285802: AArch64: Consistently handle offsets in
 MacroAssembler as 64-bit quantities
In-Reply-To: <srSJb4PGa-IkANeqDg-sNNw5Te4peY50RSE5UtKqIOc=.22437ad1-0bc5-4443-864f-cf2012d3a773@github.com>
References: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>
 <H_7VkR7T01rxzuWhuELMkrNOKzS6qDdaVKAMeK0R07E=.fb3ceb8b-b980-4691-9ff2-7f011ac9f9b7@github.com>
 <srSJb4PGa-IkANeqDg-sNNw5Te4peY50RSE5UtKqIOc=.22437ad1-0bc5-4443-864f-cf2012d3a773@github.com>
Message-ID: <tArNgdfbAxEW_WyPHS67DL4O588-0P6W7skYUrrgy0A=.7b3e32bd-1b3a-44ba-9925-5f24be38b0e3@github.com>

On Wed, 29 Jun 2022 08:46:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > I take this should now be replaced by https://bugs.openjdk.org/browse/JDK-8285923 ?
> 
> Possibly not. Mainline has changed a great deal, so backporting becomes very tricky and involves a bunch of other changes if it is to be stable. At minimum, there were additional patches. Unless this is seriously biting people on 8 I wouldn't.

Ok, I'm just trying to understand where we are with this, given 8285802 in trunk was backed out and replaced with 8285923. Do you still plan to backport any of this to 8u or shall we just close this PR?

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

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

From aph at openjdk.org  Thu Jun 30 14:08:51 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 30 Jun 2022 14:08:51 GMT
Subject: [jdk8u-dev] RFR: 8285802: AArch64: Consistently handle offsets in
 MacroAssembler as 64-bit quantities
In-Reply-To: <tArNgdfbAxEW_WyPHS67DL4O588-0P6W7skYUrrgy0A=.7b3e32bd-1b3a-44ba-9925-5f24be38b0e3@github.com>
References: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>
 <H_7VkR7T01rxzuWhuELMkrNOKzS6qDdaVKAMeK0R07E=.fb3ceb8b-b980-4691-9ff2-7f011ac9f9b7@github.com>
 <srSJb4PGa-IkANeqDg-sNNw5Te4peY50RSE5UtKqIOc=.22437ad1-0bc5-4443-864f-cf2012d3a773@github.com>
 <tArNgdfbAxEW_WyPHS67DL4O588-0P6W7skYUrrgy0A=.7b3e32bd-1b3a-44ba-9925-5f24be38b0e3@github.com>
Message-ID: <ZFAyX-tz9IuyA2JI9VX5eugry545Z6YWhNtFeDr1Mgw=.0730e94a-a773-4999-bcbe-793c4d251894@github.com>

On Thu, 30 Jun 2022 14:00:22 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Ok, I'm just trying to understand where we are with this, given 8285802 in trunk was backed out and replaced with 8285923. Do you still plan to backport any of this to 8u or shall we just close this PR?

Yes, we should close it, unless someone actually needs it in production.

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

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