From itakiguchi at openjdk.java.net  Sun May  1 04:51:17 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sun, 1 May 2022 04:51:17 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

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

  8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8378/files
  - new: https://git.openjdk.java.net/jdk/pull/8378/files/89ee195a..050dd663

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

  Stats: 106 lines in 4 files changed: 26 ins; 41 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8378/head:pull/8378

PR: https://git.openjdk.java.net/jdk/pull/8378

From itakiguchi at openjdk.java.net  Sun May  1 04:51:18 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sun, 1 May 2022 04:51:18 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <0oFVCJWhQrze7dIhCE5j3VfKkWW-XkW40UduBmB_KiE=.2c75dc1b-415a-4e41-bb9f-5e32dfd7f470@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <0oFVCJWhQrze7dIhCE5j3VfKkWW-XkW40UduBmB_KiE=.2c75dc1b-415a-4e41-bb9f-5e32dfd7f470@github.com>
Message-ID: <pHhXVFBLrw6QMurHClTcHBhNZrntKjfnuCqaPttnxeE=.215ebd9e-c48b-485b-86a8-c5c889b307c2@github.com>

On Tue, 26 Apr 2022 21:17:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> Thanks for fixing the issue.
> As to the test, it has lots of redundancy, and too complicated to me. Can you simplify the test?

Hello @naotoj and @RogerRiggs .
I appreciate your comments.
I applied the changes.
Additionally, I put bugid into test/jdk/java/lang/ProcessBuilder/Basic.java

> src/java.base/unix/classes/java/lang/ProcessImpl.java line 146:
> 
>> 144:     private static final LaunchMechanism launchMechanism = platform.launchMechanism();
>> 145:     private static final byte[] helperpath = toCString(StaticProperty.javaHome() + "/lib/jspawnhelper");
>> 146:     private static Charset jnuCharset = null;
> 
> Can we simply call `jnuCharset()` here?

Change jnuCharset to "private static".

> test/jdk/java/lang/ProcessBuilder/Basic.java line 605:
> 
>> 603:             String fileEncoding = System.getProperty("file.encoding");
>> 604:             Charset cs;
>> 605:             if (nativeEncoding != null && !nativeEncoding.equals(fileEncoding)) {
> 
> What's the reason for comparing `file.encoding`? Does `Charset.forName(nativeEncoding, Charset.defaultCharset())` suffice?

Remove file.encoding related code.

> test/jdk/java/lang/System/i18nEnvArg.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 8285517
> 
> If the test should work only on a particular env, should describe here and add `@requires`  tag.

Add "@requires (os.family == "linux")"

> test/jdk/java/lang/System/i18nEnvArg.java line 50:
> 
>> 48: 
>> 49:     public static void main(String[] args) throws Exception {
>> 50:         ProcessBuilder pb = new ProcessBuilder(javeExe,
> 
> Can utilize `jdk.test.lib.process.ProcessTools`.

Use ProcessTools class.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From itakiguchi at openjdk.java.net  Sun May  1 04:51:20 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sun, 1 May 2022 04:51:20 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <RxOobLw-G6fiPyuPSbhvz4GTXIg1agpqpLl7NAuibhw=.263471f1-78e5-42c7-bf9f-2bdee2a65a3c@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <RxOobLw-G6fiPyuPSbhvz4GTXIg1agpqpLl7NAuibhw=.263471f1-78e5-42c7-bf9f-2bdee2a65a3c@github.com>
Message-ID: <8jml3eBwwVUS5KSKW7qU7oxBPpSTs_51Adi8_LQbTTA=.f2593f06-9c5f-4595-871d-91a7d3837c4a@github.com>

On Wed, 27 Apr 2022 17:20:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 68:
> 
>> 66:     private static final Map<String,String> theUnmodifiableEnvironment;
>> 67:     static final int MIN_NAME_LENGTH = 0;
>> 68:     static final Charset cs = Charset.forName(StaticProperty.nativeEncoding(),
> 
> cs should have an all-CAPS name to make it clear its a static value throughout the implementation.
> And `private` too.

Change to "private static final"

> test/jdk/java/lang/System/i18nEnvArg.java line 41:
> 
>> 39: 
>> 40: public class i18nEnvArg {
>> 41:     final static String text = "\u6F22\u5B57";
> 
> Can this be renamed to indicate it is the string under test?  like KANJI_TEXT or EUC_JP_TEXT or similar.

Use EUC_JP_TEXT

> test/jdk/java/lang/System/i18nEnvArg.java line 49:
> 
>> 47:     final static int maxSize = 4096;
>> 48: 
>> 49:     public static void main(String[] args) throws Exception {
> 
> There are 3 main()'s in this test; it would be useful to add a comment indicating the purpose of each.

Add comments

> test/jdk/java/lang/System/i18nEnvArg.java line 60:
> 
>> 58:         Process p = pb.start();
>> 59:         InputStream is = p.getInputStream();
>> 60:         byte[] ba = new byte[maxSize];
> 
> You can use `InputStream.readAllBytes()` here to return a byte buffer.
> 
> Its not clear why all the bytes are read?  I assume its only for a possible error from the child.

Use InputStream.readAllBytes()

> test/jdk/java/lang/System/i18nEnvArg.java line 128:
> 
>> 126:             Method enviorn_mid = cls.getDeclaredMethod("environ");
>> 127:             enviorn_mid.setAccessible(true);
>> 128:             byte[][] environ = (byte[][]) enviorn_mid.invoke(null,
> 
> typo: "enviorn_mid" -> "environ_mid".

Fix typo

> test/jdk/java/lang/System/i18nEnvArg.java line 138:
> 
>> 136:                 bb.put(environ[i+1]);
>> 137:                 byte[] envb = Arrays.copyOf(ba, bb.position());
>> 138:                 if (Arrays.equals(kanji, envb)) return;
> 
> It seems odd to exit the loop on the first match.
> 
> I think AIX always has environment variables not set by the caller.

On this testing, use 2 environment variables:
* LANG=ja_JP.eucjp
* \u6F22\u5B57=\u6F22\u5B57

If the other environment variable is defined, it's printed.

> test/jdk/java/lang/System/i18nEnvArg.java line 146:
> 
>> 144:                         sb.append((char)b);
>> 145:                     } else {
>> 146:                         sb.append(String.format("\\x%02X", (int)b & 0xFF));
> 
> The methods of java.util.HexFormat may be useful here.
> It seems that the "5C" would fit into this "else" clause and not need a separate statement.

Use HexFormat class

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From dl at openjdk.java.net  Sun May  1 12:29:04 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Sun, 1 May 2022 12:29:04 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19
Message-ID: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>

This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090

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

Commit messages:
 - whitespace
 - sync with loom
 - 8276202: LogFileOutput.invalid_file_vm asserts when being executed from a read only working directory
 - 8284981: Support the vectorization of some counting-down loops in SLP
 - 8284992: Fix misleading Vector API doc for LSHR operator
 - 8254759: [TEST_BUG] [macosx] javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails
 - 8285945: [BACKOUT] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities
 - 8284331: Add sanity check for signal handler modification warning.
 - 8285773: Replace Algorithms.eatMemory(...) with WB.fullGC() in vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
 - 8284883: JVM crash: guarantee(sect->end() <= sect->limit()) failed: sanity on AVX512
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/3d07b3c7...501a21e8

Changes: https://git.openjdk.java.net/jdk/pull/8490/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8490&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277090
  Stats: 3750 lines in 30 files changed: 2060 ins; 656 del; 1034 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8490.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8490/head:pull/8490

PR: https://git.openjdk.java.net/jdk/pull/8490

From dl at cs.oswego.edu  Sun May  1 12:52:51 2022
From: dl at cs.oswego.edu (Doug Lea)
Date: Sun, 1 May 2022 08:52:51 -0400
Subject: RFR: 8277090 : jsr166 refresh for jdk19
In-Reply-To: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
Message-ID: <a5c6ed50-5b67-39b0-b317-e2fa44687bbc@cs.oswego.edu>

On 5/1/22 08:29, Doug Lea wrote:
> This is the jsr166 refresh for jdk19. Seehttps://bugs.openjdk.java.net/browse/JDK-8285450  andhttps://bugs.openjdk.java.net/browse/JDK-8277090

Hopefully a harmless glitch: An initially bad merge with 
(https://github.com/openjdk/jdk/commit/bba456a8dbf9027e4b015567c17a79fc7441aa08 
8285676: Add missing @param <https://github.com/param> tags for type 
parameters on classes) caused some unrelated commits to be added to this 
PR.


>
> -------------
>
> Commit messages:
>   - whitespace
>   - sync with loom
>   - 8276202: LogFileOutput.invalid_file_vm asserts when being executed from a read only working directory
>   - 8284981: Support the vectorization of some counting-down loops in SLP
>   - 8284992: Fix misleading Vector API doc for LSHR operator
>   - 8254759: [TEST_BUG] [macosx] javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails
>   - 8285945: [BACKOUT] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities
>   - 8284331: Add sanity check for signal handler modification warning.
>   - 8285773: Replace Algorithms.eatMemory(...) with WB.fullGC() in vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
>   - 8284883: JVM crash: guarantee(sect->end() <= sect->limit()) failed: sanity on AVX512
>   - ... and 6 more:https://git.openjdk.java.net/jdk/compare/3d07b3c7...501a21e8
>
> Changes:https://git.openjdk.java.net/jdk/pull/8490/files
>   Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=8490&range=00
>    Issue:https://bugs.openjdk.java.net/browse/JDK-8277090
>    Stats: 3750 lines in 30 files changed: 2060 ins; 656 del; 1034 mod
>    Patch:https://git.openjdk.java.net/jdk/pull/8490.diff
>    Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/8490/head:pull/8490
>
> PR:https://git.openjdk.java.net/jdk/pull/8490

From forax at openjdk.java.net  Sun May  1 14:42:55 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sun, 1 May 2022 14:42:55 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19
In-Reply-To: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
Message-ID: <b9yIvjhbR0MBC7plzteME38dHDK6pCPwqvKcl9I5MQA=.b9d6a0f2-21f2-4b01-8c4f-27fca7cd4c7c@github.com>

On Sun, 1 May 2022 10:53:55 GMT, Doug Lea <dl at openjdk.org> wrote:

> This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090

src/java.base/share/classes/java/util/concurrent/ExecutorService.java line 138:

> 136:  * @author Doug Lea
> 137:  */
> 138: public interface ExecutorService extends Executor, AutoCloseable {

The class documentation should be expanded to explain that an ExecutorService can be used with a try-with-resources

src/java.base/share/classes/java/util/concurrent/FutureTask.java line 222:

> 220:                 throw new IllegalStateException("Task has not completed");
> 221:         }
> 222:     }

I think the code will be more readable if a switch expression and the arrow syntax are used


return switch(state()) {
    case SUCCESS -> {
        @SuppressWarnings("unchecked")
        V result = (V) outcome;
        yield result;
    } 
    case FAILED -> throw new IllegalStateException("Task completed with exception");
    ...
};

src/java.base/share/classes/java/util/concurrent/FutureTask.java line 237:

> 235:                 throw new IllegalStateException("Task has not completed");
> 236:         }
> 237:     }

Same here !

src/java.base/share/classes/java/util/concurrent/FutureTask.java line 247:

> 245:             s = state;
> 246:         }
> 247:         switch (s) {

same here !

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From duke at openjdk.java.net  Sun May  1 17:48:39 2022
From: duke at openjdk.java.net (Yasser Bazzi)
Date: Sun, 1 May 2022 17:48:39 GMT
Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v21]
In-Reply-To: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
References: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
Message-ID: <4w0QnRsUSRuWQ1idjWGJbaj4GlE0MNBLblzCNIv46oA=.9237162f-3aaf-461a-9d5f-d5e5131a332e@github.com>

> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface.
> 
> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it.
> 
> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4

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

  Update specs of setSeed() and next(bits).

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7001/files
  - new: https://git.openjdk.java.net/jdk/pull/7001/files/a7c1818c..a28ba8e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=19-20

  Stats: 35 lines in 1 file changed: 8 ins; 11 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7001.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001

PR: https://git.openjdk.java.net/jdk/pull/7001

From duke at openjdk.java.net  Sun May  1 17:48:39 2022
From: duke at openjdk.java.net (Yasser Bazzi)
Date: Sun, 1 May 2022 17:48:39 GMT
Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v20]
In-Reply-To: <HtzrBgqCSFojC7IBMWpx6Pt9vkLthcnyLQpSW95JtmA=.3bc61a82-9a33-4976-8019-d08e42ba1ac5@github.com>
References: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
 <HtzrBgqCSFojC7IBMWpx6Pt9vkLthcnyLQpSW95JtmA=.3bc61a82-9a33-4976-8019-d08e42ba1ac5@github.com>
Message-ID: <Ja1Do9b5jKwkOfbaeLB7zm97Vx8RiHWC9FOzJba-fHg=.4bb7fd21-88ea-4b6e-ae0c-fc0b7c9f6d80@github.com>

On Thu, 21 Apr 2022 03:48:21 GMT, Yasser Bazzi <duke at openjdk.java.net> wrote:

>> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface.
>> 
>> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it.
>> 
>> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4
>
> Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update setSeed docs on Random class
>  - Add nicer toString method to random wrapper

Merged the changes you proposed, please review

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

PR: https://git.openjdk.java.net/jdk/pull/7001

From joehw at openjdk.java.net  Mon May  2 01:02:42 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 2 May 2022 01:02:42 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v2]
In-Reply-To: <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>
Message-ID: <b_VHYrZQJCfiufdnH1DYKZ6LkBcsbQVfenwTsMQWN6s=.e3870a71-f7d2-4676-98b7-cc1ce02f16f2@github.com>

On Fri, 29 Apr 2022 13:31:30 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating last modified tag and XRTreeFragSelectWrapper.java

Looks good.

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

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8318

From alanb at openjdk.java.net  Mon May  2 06:24:21 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 2 May 2022 06:24:21 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v9]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <LXp0tyaigLgDbl9mb2IudAI3T6CKbp5FsHbuaEhus64=.8320aa51-38bb-430d-983c-56b9036827a5@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
 - Merge with jdk-19+19
 - Refresh
 - Refresh
 - Refresh
 - Refresh
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/16a8ebbf...51bc652d

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=08
  Stats: 103888 lines in 1143 files changed: 93996 ins; 4227 del; 5665 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From jpai at openjdk.java.net  Mon May  2 06:25:28 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 2 May 2022 06:25:28 GMT
Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts
 file [v2]
In-Reply-To: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
References: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
Message-ID: <1dGZqNYHArw0QW_tY2GZJ1zbKTRuiI0R3aI7RjTsn8Q=.36ef7f58-0c9c-4aa8-aa67-677ca9774a50@github.com>

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915?
> 
> With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail.
> 
> Testing done (on macOS):
> 
> 
> cd test/failure_handler 
> make test
> 
> Then verified that the generated environment.html had the `/etc/hosts` file content

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

  print contents of hosts file in windows failure handler

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8466/files
  - new: https://git.openjdk.java.net/jdk/pull/8466/files/673fd0bd..8591d0c0

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

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8466.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8466/head:pull/8466

PR: https://git.openjdk.java.net/jdk/pull/8466

From jpai at openjdk.java.net  Mon May  2 06:25:33 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 2 May 2022 06:25:33 GMT
Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts
 file
In-Reply-To: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
References: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
Message-ID: <xa3QaK7UIpWyGOJ9PdnpmwQdPjvFlIfk9NHnigBiovw=.e1d54c3e-5180-43d3-ac0f-8c1784dd4c7e@github.com>

On Fri, 29 Apr 2022 11:28:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915?
> 
> With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail.
> 
> Testing done (on macOS):
> 
> 
> cd test/failure_handler 
> make test
> 
> Then verified that the generated environment.html had the `/etc/hosts` file content

Hello Erik, I've updated the PR to include capturing the contents of hosts file even on Windows. I've tested this against an internal Windows system where it correct shows the content:


----------------------------------------
[2022-05-02 06:08:52] [C:\cygwin\bin\bash.exe, -c, cat $WINDIR/System32/drivers/etc/hosts] timeout=20000
----------------------------------------
# ....

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost
----------------------------------------
[2022-05-02 06:08:52] exit code: 0 time: 57 ms
----------------------------------------

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

PR: https://git.openjdk.java.net/jdk/pull/8466

From alanb at openjdk.java.net  Mon May  2 06:33:22 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 2 May 2022 06:33:22 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <zi26K5BcvOD4orgtEdUoZJ3YtSkQq2LG9bsqo73bAsc=.a437c818-7bb5-4e43-835c-49fa6c4ec510@github.com>
 <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com>
Message-ID: <Hy7L4hTspFwCHXS0TokPH_lBEMMBcZjTAC6D7MJW3uM=.09fb5f13-c986-4ca5-a20b-a289d78d4edb@github.com>

On Fri, 29 Apr 2022 20:57:01 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> test/jdk/jdk/jfr/api/consumer/TestManyRecordings.java line 57:
>> 
>>> 55:         int classLoaderCount = Integer.parseInt(args[0]);
>>> 56:         int classCount = Integer.parseInt(args[1]);
>>> 57:         for (int i = 0; i <classCount; i++) {
>> 
>> Did you mean classLoaderCount here instead of classCount? Also, please make sure there is a space between < and classLoaderCount.
>
> The JFR "tests" look strange. I would expect a test called TestManyRecording to start recordings, not create a lot of classes, similar to TestManyClasses. How is this related to Loom?  Could this be a merge gone bad?
> 
> Also, in TestActiveSettingEvent.java
> 
> +settingValues.put(EventNames.VirtualThreadPinned + "#threshold", "20 ms");
> 
> The reason to exclude a setting (threshold or stackTrace) from a .jfc file is if it doesn't make sense to configure. For example, if the event is always instantaneous (so duration is always 0) or periodic (so the stack trace only show JFR internals) then "threshold" and "stackTrace" can be removed from the configuration file, but needs to be added to test to avoid false positive.
> 
> The value "20 ms" seems like something a user might want to configure. If the event is instant, then the value should be "0 ms".

It seems that test/jdk/jdk/jfr/api/consumer/TestManyClasses.java, TestManyRecordings.java, and TestParse.java were added for another JFR event (nothing to do with VirtualThreadPinned). @egahlin has contributed some cleanup and these files are removed.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Mon May  2 06:33:23 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 2 May 2022 06:33:23 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ycstoIkpgIuaPPuUzJJl0WbTB9d2fgNzsmMGAkaLg5g=.b596ebbd-0f27-4911-a1f4-f0e6c98dcbe9@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ycstoIkpgIuaPPuUzJJl0WbTB9d2fgNzsmMGAkaLg5g=.b596ebbd-0f27-4911-a1f4-f0e6c98dcbe9@github.com>
Message-ID: <Ihkc2WEFbT66Mp-11wmQKxr7tb2FAnCWUX-AEOFKogg=.5f0069b9-6bff-44e4-b78e-dc261b7719b2@github.com>

On Fri, 29 Apr 2022 23:14:45 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/lib/jdk/test/lib/thread/VThreadRunner.java line 61:
> 
>> 59:     /**
>> 60:      * Run a task in a virtual thread and wait for it to terminate.
>> 61:      * If the task completse with an exception then it is thrown by this method.
> 
> typo: completse --> completes

Thanks, it seems this typo was repeated several times in the test.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From sminervini.prism at protonmail.com  Mon May  2 06:58:08 2022
From: sminervini.prism at protonmail.com (sminervini.prism)
Date: Mon, 02 May 2022 06:58:08 +0000
Subject: OpenJDK or SE Java Floating Point Options?
In-Reply-To: <neXKPr0uJLtlh04Sdx2QcoQUzkpu56UItfg_EkerqoQIoN_8JbAKu8UMIuef_P_luRtG6Ye8TmNnu8nuwH5UC9-vQGp0aUvXfsb1iTOZwE4=@protonmail.com>
References: <neXKPr0uJLtlh04Sdx2QcoQUzkpu56UItfg_EkerqoQIoN_8JbAKu8UMIuef_P_luRtG6Ye8TmNnu8nuwH5UC9-vQGp0aUvXfsb1iTOZwE4=@protonmail.com>
Message-ID: <ScvLpgzgWo2FoW7isoAOMBohjMDTFz25xnwU_nfa7pvcYnv14fggvuLsWHod8eLMzeJ0V7Jguv1QR1F7noBSuR_tFK26zEmXTp_lNm0YxBo=@protonmail.com>

To core-libs-dev, and Glavo,

this inner nature of C++, simply means that the floating point equation can be altered in the decimal
direction; the beginning of value degredation could be altered in the equation to be entirely outside
number type's the range.  C++'s "apparent floating point" and SSE, and SSE descendents, are still a
solution to look for which I suggest to OpenJDK and JCP.

It is still the case that I and others need Java floating point and StrictMath
(the key double type calculator class) to be repaired of their denormal and pronormal errors and the circumstances
creating such. Such repair is possible, using an SSE oriented approach, while maintaining the current ranges of
float and double.

Their ranges seem to be:

float:  from 1.40129846432481707e-45   to 3.40282346638528860e+38   (positive or negative).
double: from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative).

As I attempted to submit in my previous  message to core-libs-dev, IEEE 754 is silent on pertinent matters
around floating point arithmetic, mainly certain end facts concluding binary and decimal
use in computer software; the need to have range objectivity. The proper precedent to draw from is not a
standard with a small "blind spot", due to reciprocal exponential terms alone, but the phenomenon which
simply states that both information and behaviour can be encoded into a computer, so that such a machine
will behave by means of that information rapidly, consistently, and usefully (therefore meaningfully),
to the advantage of humans.

Range any decimal mathematics, including floating point, should be for humans, and binary
mathematics is for computers. Therefore, for any decimal result to have proper meaning,
it must be entirely correct within its (rational, truncated) range. The most meaningfull thing
to do, while creating the least number of language disturbances,  is to utilise
additional (SEE and similar) registers, with appropriate sub-java (implementation) code, to use all registry
space, including the extra space if needed, to produce range accurate Java results
via improved operational logic.  It is known that having a little more registry space past
the number (result range) limit, for use and consideration, is the only range, base-10
perfect way to go.  It is certainly better than the available class approaches, which
waste memory, speed, and lack important and appropriate auxiliary use options. It is also the case
that asymptotic number generation from the floating point equation that Java uses can be offset
to occur outside of the end point of the decimal values range end.

May the Java Community Process reconsider the present floating point operations and method calls
situation, based on an imperfect standard and improper operation improper and workarounds, and
provide corrected, defaulting or specified compatible ways for Java floating point arithmetic and
Calculator class method results to always cohere in their ranges, without denormal and pronormal
inclusions whatsoever?

From ssahoo at openjdk.java.net  Mon May  2 07:18:42 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Mon, 2 May 2022 07:18:42 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v8]
In-Reply-To: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
Message-ID: <l9Y5fHwk7afrq7i4-uml5mRytymGwb4brOeyx3-BiWk=.93ed4ce4-5bb6-4c80-abd1-0fe477946316@github.com>

> A new API to support replacing selective lines with desired content.

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

  8285452: Tests updated

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8360/files
  - new: https://git.openjdk.java.net/jdk/pull/8360/files/0b7dc2f9..ff0f9cba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=06-07

  Stats: 292 lines in 3 files changed: 141 ins; 144 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8360.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8360/head:pull/8360

PR: https://git.openjdk.java.net/jdk/pull/8360

From duke at openjdk.java.net  Mon May  2 07:42:43 2022
From: duke at openjdk.java.net (Shruthi)
Date: Mon, 2 May 2022 07:42:43 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v2]
In-Reply-To: <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>
Message-ID: <KgMTSXgQpF3NOHQx8y9rxMKafJMWGjvd4MPo2irnzU0=.63d20ba0-1c52-4e3d-b277-15be857a9efc@github.com>

On Fri, 29 Apr 2022 13:31:30 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating last modified tag and XRTreeFragSelectWrapper.java

`/integrate`

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Mon May  2 08:08:37 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 2 May 2022 08:08:37 GMT
Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to
 reduce allocation pressure
In-Reply-To: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
References: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
Message-ID: <xMXWBXD3G5qbImbAt_6w-dxv5WLajKFEzuPlJVQfMyY=.5b74ad5b-21c5-4999-b4b0-46c2255da181@github.com>

On Sat, 5 Mar 2022 13:07:56 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from.

Let's wait a bit

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

PR: https://git.openjdk.java.net/jdk/pull/7714

From patrick at reini.net  Mon May  2 09:05:15 2022
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 2 May 2022 11:05:15 +0200
Subject: 8285445: Would it make sense to add an
 java.nio.channels.FileChannel::nullFileChannel()
Message-ID: <0ff0c673-3666-ddf9-a3af-c89f917efd9b@reini.net>

Hi Brian & Alan,

I just run also into this issue and saw that that Alan suggested the use 
of OutputStream.nullOutputStream() that we implemented a while ago:

https://bugs.openjdk.java.net/browse/JDK-8285445?focusedCommentId=14490595&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14490595

In the specific case I ran into was, that this problem was also in the a 
widely used library org.jboss.xnio:xnio-nio where they actually would 
like to have a null FileChannel.I wonder if it make sense to create an 
according issune and start creating an according proposal for that 
relating to https://bugs.openjdk.java.net/browse/JDK-6852033

Regards

Patrick


From dl at openjdk.java.net  Mon May  2 10:26:41 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Mon, 2 May 2022 10:26:41 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19
In-Reply-To: <b9yIvjhbR0MBC7plzteME38dHDK6pCPwqvKcl9I5MQA=.b9d6a0f2-21f2-4b01-8c4f-27fca7cd4c7c@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <b9yIvjhbR0MBC7plzteME38dHDK6pCPwqvKcl9I5MQA=.b9d6a0f2-21f2-4b01-8c4f-27fca7cd4c7c@github.com>
Message-ID: <s1Ejqzaqce1TVwTfjOhMxoTkSCMSbX9CnzowJF0pVnY=.b1fa72ef-acbd-492c-bacb-8d5cc1eba5ca@github.com>

On Sun, 1 May 2022 14:37:43 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090
>
> src/java.base/share/classes/java/util/concurrent/ExecutorService.java line 138:
> 
>> 136:  * @author Doug Lea
>> 137:  */
>> 138: public interface ExecutorService extends Executor, AutoCloseable {
> 
> The class documentation should be expanded to explain that an ExecutorService can be used with a try-with-resources

Most AutoCloseables do not mention this in class-level javadocs. Is there a reason you think this one should?

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From forax at openjdk.java.net  Mon May  2 10:45:40 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 2 May 2022 10:45:40 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19
In-Reply-To: <s1Ejqzaqce1TVwTfjOhMxoTkSCMSbX9CnzowJF0pVnY=.b1fa72ef-acbd-492c-bacb-8d5cc1eba5ca@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <b9yIvjhbR0MBC7plzteME38dHDK6pCPwqvKcl9I5MQA=.b9d6a0f2-21f2-4b01-8c4f-27fca7cd4c7c@github.com>
 <s1Ejqzaqce1TVwTfjOhMxoTkSCMSbX9CnzowJF0pVnY=.b1fa72ef-acbd-492c-bacb-8d5cc1eba5ca@github.com>
Message-ID: <lLOGt-hlt4Ti7bpIFcMLMQweH4k1Ef3AtTWbmc7HbBI=.593a72d2-40ae-4112-a714-bb7bfcf98b85@github.com>

On Mon, 2 May 2022 10:23:01 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ExecutorService.java line 138:
>> 
>>> 136:  * @author Doug Lea
>>> 137:  */
>>> 138: public interface ExecutorService extends Executor, AutoCloseable {
>> 
>> The class documentation should be expanded to explain that an ExecutorService can be used with a try-with-resources
>
> Most AutoCloseables do not mention this in class-level javadocs. Is there a reason you think this one should?

close() is now equivalent to the method shutdownAndAwaitTermination() shown in the javadoc so i believe , replacing it with a try-with-resources is better in term of documenting how an executor service can be used

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From iwalulya at openjdk.java.net  Mon May  2 10:53:49 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 2 May 2022 10:53:49 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java
 heap areas [v3]
In-Reply-To: <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
 <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>
Message-ID: <bI0mkT583P8w8ovDRfg8vKsCR_LzhrEDPKaQjxBFBHE=.a2ec1292-b9cd-4a9f-866a-d6799a189221@github.com>

On Mon, 11 Apr 2022 14:55:32 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that adds dedicated filler objects to the VM?
>> 
>> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays.
>> 
>> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array.
>> 
>> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap.
>> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification.
>> 
>> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above.
>> 
>> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays.
>> 
>> This has the following benefits:
>> 
>> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this)
>> 
>> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear.
>> 
>> This causes some minor changes to external behavior:
>> 
>> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik.
>> 
>> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects.
>> 
>> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient.
>> 
>> 
>> Testing: tier1-8
>> 
>> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines.
>> 
>> Thanks go to @iklam for helping out with the change.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8156

From tschatzl at openjdk.java.net  Mon May  2 11:06:46 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 2 May 2022 11:06:46 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java
 heap areas [v3]
In-Reply-To: <ou-Am6j5ptetpKVcJN1K4_dnEiV0jvKsSTNMmFUJGMc=.67a0811f-2122-43e9-a77e-829737e294de@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
 <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>
 <ou-Am6j5ptetpKVcJN1K4_dnEiV0jvKsSTNMmFUJGMc=.67a0811f-2122-43e9-a77e-829737e294de@github.com>
Message-ID: <Z1TbPtXS8yuhUV3hz7PQqT4CgETpqoSgJNdaNA4xnSE=.317655ab-72b5-431e-b3ad-fe9351ca1389@github.com>

On Fri, 29 Apr 2022 16:45:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test
>
> The latest version looks good to me.

Thanks @iklam @walulyai for your reviews

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

PR: https://git.openjdk.java.net/jdk/pull/8156

From tschatzl at openjdk.java.net  Mon May  2 11:06:46 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 2 May 2022 11:06:46 GMT
Subject: RFR: 8284435: Add dedicated filler objects for known dead Java
 heap areas [v3]
In-Reply-To: <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
 <JixzH0oyNSqg1RpvkZ2IOmsKWffVZ55l7Ut08ibX9s0=.0864390a-fb9a-4e03-8e95-0ad834bdae22@github.com>
Message-ID: <4THz_V9CeiHcEijqB1zA14uHlZ2FhSjNrmYBfmM0VJo=.69b50b2c-5ca8-4284-b782-bbbae52b1dc4@github.com>

On Mon, 11 Apr 2022 14:55:32 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that adds dedicated filler objects to the VM?
>> 
>> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays.
>> 
>> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array.
>> 
>> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap.
>> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification.
>> 
>> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above.
>> 
>> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays.
>> 
>> This has the following benefits:
>> 
>> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this)
>> 
>> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear.
>> 
>> This causes some minor changes to external behavior:
>> 
>> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik.
>> 
>> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects.
>> 
>> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient.
>> 
>> 
>> Testing: tier1-8
>> 
>> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines.
>> 
>> Thanks go to @iklam for helping out with the change.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test

Note that I did a tier1-5 run with the latest change with no issues before pushing.

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

PR: https://git.openjdk.java.net/jdk/pull/8156

From tschatzl at openjdk.java.net  Mon May  2 11:06:48 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 2 May 2022 11:06:48 GMT
Subject: Integrated: 8284435: Add dedicated filler objects for known dead Java
 heap areas
In-Reply-To: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
References: <tm7wytEZ2AciH_0eZpxk4jJ5qqqjf_PPzMK9zAUydNE=.46f3c3aa-ea30-4161-af3f-1214376bfd78@github.com>
Message-ID: <F_meidKYHenK-sIkxDIv8DB_CYOziiK16bB7ONifdLc=.29c41679-d3fe-4251-b90b-1f2a1e2abb1b@github.com>

On Fri, 8 Apr 2022 08:13:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that adds dedicated filler objects to the VM?
> 
> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays.
> 
> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array.
> 
> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap.
> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification.
> 
> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above.
> 
> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays.
> 
> This has the following benefits:
> 
> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this)
> 
> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear.
> 
> This causes some minor changes to external behavior:
> 
> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik.
> 
> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects.
> 
> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient.
> 
> 
> Testing: tier1-8
> 
> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines.
> 
> Thanks go to @iklam for helping out with the change.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 70205956
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70205956313740e48e1fcb0c02c8f1488ab0d987
Stats:     86 lines in 8 files changed: 80 ins; 1 del; 5 mod

8284435: Add dedicated filler objects for known dead Java heap areas

Reviewed-by: iklam, iwalulya

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

PR: https://git.openjdk.java.net/jdk/pull/8156

From simonis at openjdk.java.net  Mon May  2 12:32:25 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 2 May 2022 12:32:25 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v8]
In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
Message-ID: <uzeDkNKAhJdnDR3_3AX6sp1RADEx-aCkeDALkcT3j3k=.994f3a2f-ba5f-468a-89ff-a0263cdf4c62@github.com>

> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
> 
> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
> 
> ### TL;DR
> 
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
> 
> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
> 
> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
> 
> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*
 k*`]` (where *k* is the number of inflated bytes).
> 
> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).

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

  Updated wording based on @JoeDarcy's CSR review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7986/files
  - new: https://git.openjdk.java.net/jdk/pull/7986/files/c9b60404..63ae3572

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=06-07

  Stats: 14 lines in 3 files changed: 0 ins; 1 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7986.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7986/head:pull/7986

PR: https://git.openjdk.java.net/jdk/pull/7986

From simonis at openjdk.java.net  Mon May  2 12:32:25 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 2 May 2022 12:32:25 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v7]
In-Reply-To: <RcPd0e6e5xsApL92Z-ggA5CXFke4Jv9MKuE42SQLaAQ=.3a2cc537-a1be-439d-b15a-573ef968dab6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <RcPd0e6e5xsApL92Z-ggA5CXFke4Jv9MKuE42SQLaAQ=.3a2cc537-a1be-439d-b15a-573ef968dab6@github.com>
Message-ID: <qpVF7S-t7D_xX8aLU87g6bai94rxB_UxTpC89fXq-ps=.f1da43a9-af3b-47eb-90de-17461ed20f3b@github.com>

On Wed, 13 Apr 2022 17:42:57 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated wording based on @LanceAndersen's review

I've slightly updated the phrasing based on @jddarcy's comments in the [CSR](https://bugs.openjdk.java.net/browse/JDK-8283758) for this PR. If you have further suggestions, please comment directly on the CSR.

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

PR: https://git.openjdk.java.net/jdk/pull/7986

From dl at openjdk.java.net  Mon May  2 12:58:02 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Mon, 2 May 2022 12:58:02 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19
In-Reply-To: <lLOGt-hlt4Ti7bpIFcMLMQweH4k1Ef3AtTWbmc7HbBI=.593a72d2-40ae-4112-a714-bb7bfcf98b85@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <b9yIvjhbR0MBC7plzteME38dHDK6pCPwqvKcl9I5MQA=.b9d6a0f2-21f2-4b01-8c4f-27fca7cd4c7c@github.com>
 <s1Ejqzaqce1TVwTfjOhMxoTkSCMSbX9CnzowJF0pVnY=.b1fa72ef-acbd-492c-bacb-8d5cc1eba5ca@github.com>
 <lLOGt-hlt4Ti7bpIFcMLMQweH4k1Ef3AtTWbmc7HbBI=.593a72d2-40ae-4112-a714-bb7bfcf98b85@github.com>
Message-ID: <-95s0CkvdZ5jUeh_STTGPH2TcxM0E_7fU-tKboTfrNY=.5197fa08-1600-487b-8379-949e592818ec@github.com>

On Mon, 2 May 2022 10:42:35 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Most AutoCloseables do not mention this in class-level javadocs. Is there a reason you think this one should?
>
> close() is now equivalent to the method shutdownAndAwaitTermination() shown in the javadoc so i believe , replacing it with a try-with-resources is better in term of documenting how an executor service can be used

OK, done (see https://bugs.openjdk.java.net/browse/JDK-8285450)

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From ssahoo at openjdk.java.net  Mon May  2 13:01:40 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Mon, 2 May 2022 13:01:40 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v9]
In-Reply-To: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
Message-ID: <HdpX4Sj-YzXVrrXrtP78xKF3zjX02CheXtOhlxagOTY=.3f8489cb-4c44-409e-8c95-3a76cd2a7e41@github.com>

> A new API to support replacing selective lines with desired content.

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

  8285452: Tests updated

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8360/files
  - new: https://git.openjdk.java.net/jdk/pull/8360/files/ff0f9cba..f73faf81

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8360&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/8360

From erikj at openjdk.java.net  Mon May  2 13:03:58 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 2 May 2022 13:03:58 GMT
Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts
 file [v2]
In-Reply-To: <1dGZqNYHArw0QW_tY2GZJ1zbKTRuiI0R3aI7RjTsn8Q=.36ef7f58-0c9c-4aa8-aa67-677ca9774a50@github.com>
References: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
 <1dGZqNYHArw0QW_tY2GZJ1zbKTRuiI0R3aI7RjTsn8Q=.36ef7f58-0c9c-4aa8-aa67-677ca9774a50@github.com>
Message-ID: <UUpRYY_JI0lzzW99tcmHyljNja51aaBprPpmIEmg4b4=.f6eed19e-1c9b-412d-a66a-aa747a32db7a@github.com>

On Mon, 2 May 2022 06:25:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915?
>> 
>> With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail.
>> 
>> Testing done (on macOS):
>> 
>> 
>> cd test/failure_handler 
>> make test
>> 
>> Then verified that the generated environment.html had the `/etc/hosts` file content
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   print contents of hosts file in windows failure handler

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8466

From raffaello.giulietti at oracle.com  Mon May  2 13:15:25 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Mon, 2 May 2022 13:15:25 +0000
Subject: OpenJDK or SE Java Floating Point Options?
In-Reply-To: <ScvLpgzgWo2FoW7isoAOMBohjMDTFz25xnwU_nfa7pvcYnv14fggvuLsWHod8eLMzeJ0V7Jguv1QR1F7noBSuR_tFK26zEmXTp_lNm0YxBo=@protonmail.com>
References: <neXKPr0uJLtlh04Sdx2QcoQUzkpu56UItfg_EkerqoQIoN_8JbAKu8UMIuef_P_luRtG6Ye8TmNnu8nuwH5UC9-vQGp0aUvXfsb1iTOZwE4=@protonmail.com>
 <ScvLpgzgWo2FoW7isoAOMBohjMDTFz25xnwU_nfa7pvcYnv14fggvuLsWHod8eLMzeJ0V7Jguv1QR1F7noBSuR_tFK26zEmXTp_lNm0YxBo=@protonmail.com>
Message-ID: <BY5PR10MB400236D94687EB35536E51E287C19@BY5PR10MB4002.namprd10.prod.outlook.com>

>> May the Java Community Process reconsider the present floating point operations [...]?

Over the past several weeks, this community has unanimously replied to your concerns with a clear: "No thanks, for the next decades we aren't interested in changing the current semantics of floating-point arithmetic in Java."

The good news for you: you don't need to spend even more of your time on this mailing list, trying to convince this reluctant community.



From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of sminervini.prism <sminervini.prism at protonmail.com>
Date: Monday, 02 May 2022 at 08:58
To: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Subject: OpenJDK or SE Java Floating Point Options?
To core-libs-dev, and Glavo,

this inner nature of C++, simply means that the floating point equation can be altered in the decimal
direction; the beginning of value degredation could be altered in the equation to be entirely outside
number type's the range.  C++'s "apparent floating point" and SSE, and SSE descendents, are still a
solution to look for which I suggest to OpenJDK and JCP.

It is still the case that I and others need Java floating point and StrictMath
(the key double type calculator class) to be repaired of their denormal and pronormal errors and the circumstances
creating such. Such repair is possible, using an SSE oriented approach, while maintaining the current ranges of
float and double.

Their ranges seem to be:

float:  from 1.40129846432481707e-45   to 3.40282346638528860e+38   (positive or negative).
double: from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative).

As I attempted to submit in my previous  message to core-libs-dev, IEEE 754 is silent on pertinent matters
around floating point arithmetic, mainly certain end facts concluding binary and decimal
use in computer software; the need to have range objectivity. The proper precedent to draw from is not a
standard with a small "blind spot", due to reciprocal exponential terms alone, but the phenomenon which
simply states that both information and behaviour can be encoded into a computer, so that such a machine
will behave by means of that information rapidly, consistently, and usefully (therefore meaningfully),
to the advantage of humans.

Range any decimal mathematics, including floating point, should be for humans, and binary
mathematics is for computers. Therefore, for any decimal result to have proper meaning,
it must be entirely correct within its (rational, truncated) range. The most meaningfull thing
to do, while creating the least number of language disturbances,  is to utilise
additional (SEE and similar) registers, with appropriate sub-java (implementation) code, to use all registry
space, including the extra space if needed, to produce range accurate Java results
via improved operational logic.  It is known that having a little more registry space past
the number (result range) limit, for use and consideration, is the only range, base-10
perfect way to go.  It is certainly better than the available class approaches, which
waste memory, speed, and lack important and appropriate auxiliary use options. It is also the case
that asymptotic number generation from the floating point equation that Java uses can be offset
to occur outside of the end point of the decimal values range end.

May the Java Community Process reconsider the present floating point operations and method calls
situation, based on an imperfect standard and improper operation improper and workarounds, and
provide corrected, defaulting or specified compatible ways for Java floating point arithmetic and
Calculator class method results to always cohere in their ranges, without denormal and pronormal
inclusions whatsoever?

From weijun at openjdk.java.net  Mon May  2 13:16:45 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 2 May 2022 13:16:45 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v9]
In-Reply-To: <HdpX4Sj-YzXVrrXrtP78xKF3zjX02CheXtOhlxagOTY=.3f8489cb-4c44-409e-8c95-3a76cd2a7e41@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <HdpX4Sj-YzXVrrXrtP78xKF3zjX02CheXtOhlxagOTY=.3f8489cb-4c44-409e-8c95-3a76cd2a7e41@github.com>
Message-ID: <WMBvjbj-2fXKwi_QYIQ7yHaAT6CqX-w7IRCoOFFuiwY=.160a8eed-d7d3-41ce-b3e1-a9f8b83cc198@github.com>

On Mon, 2 May 2022 13:01:40 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285452: Tests updated

Marked as reviewed by weijun (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8360

From weijun at openjdk.java.net  Mon May  2 13:16:45 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 2 May 2022 13:16:45 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v5]
In-Reply-To: <1l_DgR2KfeB1qDNJTeIzCEdEhy1wGTGnxpMUrChRvHo=.fe3bcba6-e120-40ab-b4b3-5db0fa316f48@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <A-3GCS_VCMIfss1czbRd-Dk2mdMuarJs6AjcMX5LpD4=.91358fdc-a47d-48a5-a59d-18a2c2e7b759@github.com>
 <7RAAJPEdgNo3PoeQh8bQiXvr7Hdckya1cjLDt5oweHI=.a6d309e2-7307-4d91-a708-8f70658849ca@github.com>
 <1l_DgR2KfeB1qDNJTeIzCEdEhy1wGTGnxpMUrChRvHo=.fe3bcba6-e120-40ab-b4b3-5db0fa316f48@github.com>
Message-ID: <jzzX1o_WHbLsvrstqOfeTYV7iHkxQbjxlziT1_FVYR0=.7272f1f2-c556-4340-b062-add591d73b68@github.com>

On Fri, 29 Apr 2022 15:51:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/lib/jdk/test/lib/util/FileUtils.java line 389:
>> 
>>> 387:      * @throws IOException
>>> 388:      */
>>> 389:     public static void patch(Path path, int fromLine, int toLine, String from, String to) throws IOException {
>> 
>> Should this method check whether the `fromLine` and `toLine` are valid values? Things like, negative value or 0 or `toLine` being less than `fromLine`. I'm not familiar with the expectations of test library code - maybe those checks aren't necessary since this is a test util?
>
> `lines.remove()` and `lines.subList()` will throw the correct exception. Since you asked, we can add it.

Now that we call `subList` at the beginning, I think there's no need to explicitly perform a check.

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

PR: https://git.openjdk.java.net/jdk/pull/8360

From dl at openjdk.java.net  Mon May  2 13:33:33 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Mon, 2 May 2022 13:33:33 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v2]
In-Reply-To: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
Message-ID: <6o1i3zFRklC1C7giECN4v8s7591LVoKr5IWX2YkUsOk=.50b90259-d7ac-490e-8534-917362479b1c@github.com>

> This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8490/files
  - new: https://git.openjdk.java.net/jdk/pull/8490/files/501a21e8..c3901b45

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

  Stats: 40 lines in 4 files changed: 18 ins; 3 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8490.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8490/head:pull/8490

PR: https://git.openjdk.java.net/jdk/pull/8490

From lancea at openjdk.java.net  Mon May  2 14:11:50 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 2 May 2022 14:11:50 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v8]
In-Reply-To: <uzeDkNKAhJdnDR3_3AX6sp1RADEx-aCkeDALkcT3j3k=.994f3a2f-ba5f-468a-89ff-a0263cdf4c62@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <uzeDkNKAhJdnDR3_3AX6sp1RADEx-aCkeDALkcT3j3k=.994f3a2f-ba5f-468a-89ff-a0263cdf4c62@github.com>
Message-ID: <i2j4cnd_8tiT-Rsx-pYl_aXCuIWGvMRv-Ptbr01eyD4=.d592f4d1-5cb8-42f7-a374-173239311713@github.com>

On Mon, 2 May 2022 12:32:25 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated wording based on @JoeDarcy's CSR review

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7986

From duke at openjdk.java.net  Mon May  2 14:17:57 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 2 May 2022 14:17:57 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v2]
In-Reply-To: <KgMTSXgQpF3NOHQx8y9rxMKafJMWGjvd4MPo2irnzU0=.63d20ba0-1c52-4e3d-b277-15be857a9efc@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>
 <KgMTSXgQpF3NOHQx8y9rxMKafJMWGjvd4MPo2irnzU0=.63d20ba0-1c52-4e3d-b277-15be857a9efc@github.com>
Message-ID: <11arnxJER6ob3pNR_OZ8VqlBM3HMP4rs7OICbpMXVro=.3195dd50-2b50-41ac-9fca-8db84b3988fc@github.com>

On Mon, 2 May 2022 07:39:39 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating last modified tag and XRTreeFragSelectWrapper.java
>
> `/integrate`

@shruacha1234 Please don't integrate without addressing the comments left in my review. There are several files that still use the old key incorrectly.

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Mon May  2 14:17:58 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 2 May 2022 14:17:58 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v2]
In-Reply-To: <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>
Message-ID: <vXyxS4pMGNV7N6AujAJ3LezVVLjJ6SsHemjdWYRIRl4=.f12677dd-4f3d-4c86-a17e-0a5adb470b13@github.com>

On Fri, 29 Apr 2022 13:31:30 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating last modified tag and XRTreeFragSelectWrapper.java

It also looks like you have not run the pre-tests yet. Please enable them in GitHub Actions and confirm that they pass.

https://wiki.openjdk.java.net/display/SKARA/Testing

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From rriggs at openjdk.java.net  Mon May  2 15:03:46 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 2 May 2022 15:03:46 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
Message-ID: <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>

On Sun, 1 May 2022 04:51:17 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

Can you clarify the use of different charset properties for the ProcessEnvironment vs the CommandLine strings?

They are used to decode or encode strings in the APIs to native functions respectively.
If I understand `native.encoding` was introduced to reflect the default encoding of file contents, while `sun.jnu.encoding` is used to encode filenames.

I think I would have expected to see `sun.jnu.encoding` to be used in all contexts when encoding/decoding strings to the native representations.  (Assuming its not required for backward compatibility).

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From redestad at openjdk.java.net  Mon May  2 15:12:44 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 2 May 2022 15:12:44 GMT
Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to
 reduce allocation pressure
In-Reply-To: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
References: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
Message-ID: <Fa9XjLA5zskBEGB1ziMeHLQlxzKPG-pYDuU2YdIhtMw=.241bcacc-f5f9-494d-be50-3c66f0fc6805@github.com>

On Sat, 5 Mar 2022 13:07:56 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from.

I think this ok in general, but for consistency and to better call out that we're dealing with a trusted shared array I would prefer if `getInterfaces(boolean)` remains private and instead we add a `getInterfacesShared()` (which simply call `getInterfaces(false)`).

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

Changes requested by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7714

From mseledtsov at openjdk.java.net  Mon May  2 16:05:19 2022
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 2 May 2022 16:05:19 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v9]
In-Reply-To: <LXp0tyaigLgDbl9mb2IudAI3T6CKbp5FsHbuaEhus64=.8320aa51-38bb-430d-983c-56b9036827a5@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <LXp0tyaigLgDbl9mb2IudAI3T6CKbp5FsHbuaEhus64=.8320aa51-38bb-430d-983c-56b9036827a5@github.com>
Message-ID: <q-gQnc_5PSoqmpwJzQeU3OBmPHuB_6VvOPe6DgZ7NMo=.686d086e-933b-4b1a-967d-b08193d998ca@github.com>

On Mon, 2 May 2022 06:24:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - Refresh
>  - Refresh
>  - Refresh
>  - Refresh
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/16a8ebbf...51bc652d

Thank you for addressing my review feedback. HotSpot/Runtime, test library, common test and JFR test changes look good to me.

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

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From naoto at openjdk.java.net  Mon May  2 16:06:11 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 May 2022 16:06:11 GMT
Subject: RFR: 8285947: Avoid redundant HashMap.containsKey calls in
 ZoneName
In-Reply-To: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
References: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
Message-ID: <NxEbRqMXFluW3hClLwxa5Me8BUjL8pk4BILKJ9ID-9Q=.0b1d775f-cbed-4608-a2d0-f1a19a56ff22@github.com>

On Fri, 29 Apr 2022 06:31:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Map.containsKey` call is sometimes unnecessary, when it's known that Map doesn't contain `null` values.
> Instead we can just use Map.get and compare result with `null`.
> I found one of such place, where Map.containsKey calls could be eliminated - `java.time.format.ZoneName`.
> it gives a bit of performance for `toZid`.
> 
> 
> Benchmark                             Mode  Cnt   Score   Error  Units
> ZoneNamesBench.useExistingCountry     avgt    5  10,738 ? 0,065  ns/op
> ZoneNamesBench.useExistingCountryOld  avgt    5  13,679 ? 0,089  ns/op
> 
> 
> <details>
> <summary>Benchmark</summary>
> 
> 
> @BenchmarkMode(value = Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Benchmark)
> public class ZoneNamesBench {
> 
>     @Benchmark
>     public String useExistingCountry() {
>         return ZoneName.toZid("Africa/Tunis", Locale.ITALY);
>     }
> 
>     @Benchmark
>     public String useExistingCountryOld() {
>         return ZoneName.toZidOld("Africa/Tunis", Locale.ITALY);
>     }
> }
> 
> 
> 
>     public static String toZid(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null) {
>             String alias = aliases.get(zid);
>             if (alias != null) {
>                 zid = alias;
>                 mzone = zidToMzone.get(zid);
>             }
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map == null || ((zid = map.get(locale.getCountry())) == null)) {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZid(zid);
>     }
> 
>     public static String toZid(String zid) {
>         return aliases.getOrDefault(zid, zid);
>     }
> 
>     public static String toZidOld(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null && aliases.containsKey(zid)) {
>             zid = aliases.get(zid);
>             mzone = zidToMzone.get(zid);
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map != null && map.containsKey(locale.getCountry())) {
>                 zid = map.get(locale.getCountry());
>             } else {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZidOld(zid);
>     }
> 
>     public static String toZidOld(String zid) {
>         if (aliases.containsKey(zid)) {
>             return aliases.get(zid);
>         }
>         return zid;
>     }
> 
> </details>

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8463

From mchung at openjdk.java.net  Mon May  2 16:22:49 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 2 May 2022 16:22:49 GMT
Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to
 reduce allocation pressure
In-Reply-To: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
References: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
Message-ID: <XEH74-vN4e9-Pg0ck00GSmWKBCrP9sH2LrFT0wTe0sg=.c3896f6c-d78d-40ff-a911-108b36a089d3@github.com>

On Sat, 5 Mar 2022 13:07:56 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from.

For the `checkPackageAccess` case, I don't think it worths fixing; not only that security manager is deprecated for removal but also when security manager is enabled, there are lots of allocations for other security checks.

So the `getInterface(boolean)` method can be kept private.

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

PR: https://git.openjdk.java.net/jdk/pull/7714

From itakiguchi at openjdk.java.net  Mon May  2 16:39:40 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 2 May 2022 16:39:40 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
 <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
Message-ID: <BvCrLbhU6TwM8RR49hLld_19AeqoIBB9ebhzVqEZISk=.e4b484db-37b8-47a9-ae4e-373584325f16@github.com>

On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> Can you clarify the use of different charset properties for the ProcessEnvironment vs the CommandLine strings?
> 
> They are used to decode or encode strings in the APIs to native functions respectively.
> If I understand `native.encoding` was introduced to reflect the default encoding of file contents, while `sun.jnu.encoding` is used to encode filenames.
> 
> I think I would have expected to see `sun.jnu.encoding` to be used in all contexts when encoding/decoding strings to the native representations.  (Assuming its not required for backward compatibility).

Hello @RogerRiggs .
You are right. Both case, `sun.jnu.encoding` should be used.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From lmesnik at openjdk.java.net  Mon May  2 17:24:13 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 17:24:13 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ToZrjWwHwDBwSBGMmN4GhwGvTEhcPFSVF40moxWLKwQ=.f6d14c2c-02f5-4655-808e-431bca9b386e@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ToZrjWwHwDBwSBGMmN4GhwGvTEhcPFSVF40moxWLKwQ=.f6d14c2c-02f5-4655-808e-431bca9b386e@github.com>
Message-ID: <ojMUwaa-wbzazU8JX6_xaqDrJ9ASDlPApVC1iux2ncA=.19af44cd-1114-417e-b08e-c5e5a97e12e3@github.com>

On Fri, 29 Apr 2022 05:48:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 66:
> 
>> 64:   for (i = 0; i < METH_NUM; i++)
>> 65:     bpEvents[i] = 0;
>> 66: }
> 
> Leonid, thank you for converting these tests from nsk.jvmti to provide test coverage for virtual threads!
> As I understand all new tests are C++ based.
> So, I'd suggest to always use C++ style of loops:
>   for (int i = 0; i < METH_NUM; i++)
> 
> This suggestion applies to all new tests in the serviceability/jvmti folder.
> One reason to keep old style would be to keep these tests comparable with the matching nsk.jvmti tests.
> However, I tried to compare and found out that the difference is already pretty big.
> You can consider this clean up after integration though.

fixed in all ported tests were applicable

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From lmesnik at openjdk.java.net  Mon May  2 17:33:45 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 17:33:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <ZIbvg5mqBKnDkPqj_VXglNgLvfgXGoXXQeKkCdXEpog=.222d1b6a-ba31-4b24-8087-8939d91f6b40@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ZIbvg5mqBKnDkPqj_VXglNgLvfgXGoXXQeKkCdXEpog=.222d1b6a-ba31-4b24-8087-8939d91f6b40@github.com>
Message-ID: <htZ8N0SehZt8GFsN3GD8d0lvFbFlfjHdLv-PonqMYBI=.79c09d37-e6db-4746-b608-702eeca04539@github.com>

On Fri, 29 Apr 2022 06:09:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139:
> 
>> 137:            thr_info.name,        (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel",
>> 138:         (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user");
>> 139:   }
> 
> I'd suggest to add locals (their names are up to you):
>    const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel";
>    const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user";
> 
> It is better to place togeter lines: 129+130.
> Line 137 is not aligned, and there are many unneeded spaces.
> The '()' around conditions are not needed. At least, I do not see them increasing readability.

fixed

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From rriggs at openjdk.java.net  Mon May  2 18:04:16 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 2 May 2022 18:04:16 GMT
Subject: RFR: 8285947: Avoid redundant HashMap.containsKey calls in
 ZoneName
In-Reply-To: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
References: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
Message-ID: <_XCLlSWFA1r3qJKqd02vJRoxjg-zj3_h4CrN3FsUaVM=.b0bd3c03-7bdf-45a3-a621-6422dd79215a@github.com>

On Fri, 29 Apr 2022 06:31:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Map.containsKey` call is sometimes unnecessary, when it's known that Map doesn't contain `null` values.
> Instead we can just use Map.get and compare result with `null`.
> I found one of such place, where Map.containsKey calls could be eliminated - `java.time.format.ZoneName`.
> it gives a bit of performance for `toZid`.
> 
> 
> Benchmark                             Mode  Cnt   Score   Error  Units
> ZoneNamesBench.useExistingCountry     avgt    5  10,738 ? 0,065  ns/op
> ZoneNamesBench.useExistingCountryOld  avgt    5  13,679 ? 0,089  ns/op
> 
> 
> <details>
> <summary>Benchmark</summary>
> 
> 
> @BenchmarkMode(value = Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Benchmark)
> public class ZoneNamesBench {
> 
>     @Benchmark
>     public String useExistingCountry() {
>         return ZoneName.toZid("Africa/Tunis", Locale.ITALY);
>     }
> 
>     @Benchmark
>     public String useExistingCountryOld() {
>         return ZoneName.toZidOld("Africa/Tunis", Locale.ITALY);
>     }
> }
> 
> 
> 
>     public static String toZid(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null) {
>             String alias = aliases.get(zid);
>             if (alias != null) {
>                 zid = alias;
>                 mzone = zidToMzone.get(zid);
>             }
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map == null || ((zid = map.get(locale.getCountry())) == null)) {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZid(zid);
>     }
> 
>     public static String toZid(String zid) {
>         return aliases.getOrDefault(zid, zid);
>     }
> 
>     public static String toZidOld(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null && aliases.containsKey(zid)) {
>             zid = aliases.get(zid);
>             mzone = zidToMzone.get(zid);
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map != null && map.containsKey(locale.getCountry())) {
>                 zid = map.get(locale.getCountry());
>             } else {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZidOld(zid);
>     }
> 
>     public static String toZidOld(String zid) {
>         if (aliases.containsKey(zid)) {
>             return aliases.get(zid);
>         }
>         return zid;
>     }
> 
> </details>

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8463

From bpb at openjdk.java.net  Mon May  2 18:06:02 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 2 May 2022 18:06:02 GMT
Subject: RFR: 8285956: (fs) Excessive default poll interval in
 PollingWatchService
In-Reply-To: <OS0xRPi4ZKmWCKGSz6x9WbNHd90WPc3ohvlUo1QnVEE=.7387cee2-a1a6-455d-9da4-88e8b09b6ee5@github.com>
References: <OS0xRPi4ZKmWCKGSz6x9WbNHd90WPc3ohvlUo1QnVEE=.7387cee2-a1a6-455d-9da4-88e8b09b6ee5@github.com>
Message-ID: <W5X9-M8grPdgYgTYoQeFAPpu2u2tWnaSePPRFfF8XnI=.2c8ee510-47aa-43d1-a940-b8e6d3b1e315@github.com>

On Sat, 30 Apr 2022 00:14:29 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> PollingWatchService.java contains the WatchService and WatchKey implementation for AIX and BSD. When a Path is [register](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Path.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind...))ed this implementation creates a  polling thread to monitor for file system changes. Currently, this thread waits 10 seconds before it's first poll, and then waits 10 seconds between subsequent polls. This interval leads to sluggish performance.
> 
> This PR makes the following changes:
> - Sets the initial interval to 1 second regardless of the period.
> - Change the default period to 1 second.
> 
> All tests in `test/jdk/java/nio/file/WatchService` passing.

Do you have any performance measurements to share?

Note that the sensitivity can be set as shown in the [SensitivityModifier](https://github.com/openjdk/jdk/blob/41de506ed6c9dc0331c2b6ae99c11623df05f34a/test/jdk/java/nio/file/WatchService/SensitivityModifier.java) test.

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

PR: https://git.openjdk.java.net/jdk/pull/8479

From bpb at openjdk.java.net  Mon May  2 18:23:03 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 2 May 2022 18:23:03 GMT
Subject: Integrated: 8285745: Re-examine PushbackInputStream mark/reset
In-Reply-To: <znI3g_qnP9PZ--kgvUSTppiePqjn5ABF_LHUsJsn8lA=.d2814eaf-1178-48fc-a9a6-0358b0613fa5@github.com>
References: <znI3g_qnP9PZ--kgvUSTppiePqjn5ABF_LHUsJsn8lA=.d2814eaf-1178-48fc-a9a6-0358b0613fa5@github.com>
Message-ID: <f_8lOSsd2Krae5dJWieAPDX_qsDiN6UTTiYdX40SSrs=.1f357896-dfbb-40b9-84cd-c12af5084d52@github.com>

On Wed, 27 Apr 2022 20:10:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this request to remove the `synchronized` keyword from the `mark(int)` and `reset()` methods of `java.io.PushbackInputStream`.

This pull request has now been integrated.

Changeset: 9d8c3bf9
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9d8c3bf9f8bc2083c44b7203e81c007d685b9b61
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8285745: Re-examine PushbackInputStream mark/reset

Reviewed-by: jpai, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8433

From redestad at openjdk.java.net  Mon May  2 18:24:29 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 2 May 2022 18:24:29 GMT
Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to
 reduce allocation pressure
In-Reply-To: <XEH74-vN4e9-Pg0ck00GSmWKBCrP9sH2LrFT0wTe0sg=.c3896f6c-d78d-40ff-a911-108b36a089d3@github.com>
References: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
 <XEH74-vN4e9-Pg0ck00GSmWKBCrP9sH2LrFT0wTe0sg=.c3896f6c-d78d-40ff-a911-108b36a089d3@github.com>
Message-ID: <_KivtXPM1yM9v5PIVT6tj_IbbgRhU7vnxMa4L9eHsSY=.5215326c-96a7-42bc-90d5-d9deb597816f@github.com>

On Mon, 2 May 2022 16:19:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from.
>
> For the `checkPackageAccess` case, I don't think it worths fixing; not only that security manager is deprecated for removal but also when security manager is enabled, there are lots of allocations for other security checks.
> 
> So the `getInterface(boolean)` method can be kept private.

I agree with @mlchung that the call site in `ClassLoader` is not particularly interesting and doesn't motivate a non-cloning, trusted method. There are a few other places in java.base where it's used and a trusted method could help, but not sure any of those are performance critical.

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

PR: https://git.openjdk.java.net/jdk/pull/7714

From joehw at openjdk.java.net  Mon May  2 19:40:22 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 2 May 2022 19:40:22 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v2]
In-Reply-To: <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>
Message-ID: <RuWKw9RIDDNjoEuFQihXtzRiZ0zyS60fNZEvr_8QnBI=.9061ff58-ab6a-42c7-a397-a0d86b871f4c@github.com>

On Fri, 29 Apr 2022 13:31:30 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating last modified tag and XRTreeFragSelectWrapper.java

Note that I've run the tests locally. The default test configuration is tier1, which isn't really helpful in this case excepting heating up the planet. If you plan to do more on java.xml, you may run tier2 to verify your changes.

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From lmesnik at openjdk.java.net  Mon May  2 20:04:59 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 20:04:59 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <TcJvhtqkkhHL32dEDwwEwxpShTFQTt39RsQo4wyHfJo=.4c9533a1-0540-4545-8293-74aa6168d085@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <TcJvhtqkkhHL32dEDwwEwxpShTFQTt39RsQo4wyHfJo=.4c9533a1-0540-4545-8293-74aa6168d085@github.com>
Message-ID: <WkOg5zdfmYpJZrFNKGUgfrtEA2OTK1NZZMvPV3wSpBI=.063bc28c-2147-4173-892e-87287939ac7c@github.com>

On Fri, 29 Apr 2022 06:43:02 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp line 287:
> 
>> 285:   }
>> 286: 
>> 287:   eventsCount = 0;
> 
> Counters are not protected with locks.
> I'm not sure it is a real problem here but would be better to double-check.

The variable eventsCount seems to be used in the sinlge thread only. I looked on the several tests with same variable and similar logic.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From lmesnik at openjdk.java.net  Mon May  2 20:16:01 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 2 May 2022 20:16:01 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <YzgjmX7Q5pE2ckM4tdOY0tfh-TepCovgtzJKqxylvlo=.132db6f6-864d-4230-bdf9-7098512f0984@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <YzgjmX7Q5pE2ckM4tdOY0tfh-TepCovgtzJKqxylvlo=.132db6f6-864d-4230-bdf9-7098512f0984@github.com>
Message-ID: <7mvqatvgF_tC9fZB1rci31SVIh7q0JVtwGPXlWfiH9Y=.b58e30aa-101c-48d4-bed2-bcb7bf20a160@github.com>

On Fri, 29 Apr 2022 06:33:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 59:
> 
>> 57: static jvmtiEventCallbacks callbacks;
>> 58: static jint result = PASSED;
>> 59: static volatile size_t eventsCount = 0; // TODO these 2 vars mofified from different threads in getReady/check. What to DO???
> 
> I'd suggest to use RawMonitorLocker with event_lock or counter_lock to protect updates of these counters.
> You can remove this comment then.

The variable eventsCount seems to be used in the sinlge thread only. I looked on the several tests with same variable and similar logic.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From darcy at openjdk.java.net  Mon May  2 20:31:18 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 2 May 2022 20:31:18 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v6]
In-Reply-To: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
Message-ID: <vYo0UIcyKZGjaQosXWtu_MDG1TPxNz2-Oo2bfEXE_aI=.6cc54504-f465-42be-a8eb-478f9691530a@github.com>

> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
> 
> I'll update copyright years before an integration.

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

 - Update wording to address review feedback.
 - Merge branch 'master' into JDK-8285497
 - Change punctuation from review feedback.
 - Respond to review feedback; make sequence of values explicit.
 - Respond to review feedback.
 - Respond to review feedback.
 - Respond to CSR feedback.
 - Merge branch 'master' into JDK-8285497
 - Update comment in template.
 - JDK-8285497: Add system property for Java SE specification maintenance version

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8437/files
  - new: https://git.openjdk.java.net/jdk/pull/8437/files/2048aaac..741ececa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=04-05

  Stats: 13916 lines in 459 files changed: 8927 ins; 2577 del; 2412 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437

PR: https://git.openjdk.java.net/jdk/pull/8437

From darcy at openjdk.java.net  Mon May  2 20:33:16 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 2 May 2022 20:33:16 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v5]
In-Reply-To: <ComDy6I5wL37EpHF_giwqof4VNkvZzCvexm3SGukzMc=.e476bdd6-12a6-4ae0-9f8d-8dd79a20aaa4@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
 <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>
 <ComDy6I5wL37EpHF_giwqof4VNkvZzCvexm3SGukzMc=.e476bdd6-12a6-4ae0-9f8d-8dd79a20aaa4@github.com>
Message-ID: <c4xaElUahQKe72pq-zI4MWvWCWObe4oMyV8z89G8GFg=.a7d8d8dd-959c-4a7d-bdc7-227c6db2e550@github.com>

On Fri, 29 Apr 2022 17:11:55 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 743:
>> 
>>> 741:      *         have the value {@code "1"}; after a second maintenance
>>> 742:      *         release, this property will have the value {@code "2"},
>>> 743:      *         and so on.
>> 
>> There should be no requirement that values be allocated sequentially.  In other words, if JCP MR <x> does not require an RI, then it should not be surprising if there is no JDK build with maintenance version <x>.  As an example, JSR 337 MR 1 and MR 2 both used the same RI.  If this system property had existed during development of MR 1, it would return "1".  Since no RI was submitted for MR 2, a build returning "2" should never exist.  MR 3 did update the RI, so it would return "3".
>
> @irisclark does raise an interesting point: If, say, MR 2 doesn?t require a change to the RI then the MR 1 RI is also the MR 2 RI, but its `java.specification.maintenance.version` property will report that it?s the MR 1 RI.
> 
> One way to fix this would be to require an RI update with every MR just to update this property, even if no other code in the RI changes ? but we prefer to avoid doing RI builds unnecessarily.
> 
> Another way to fix it would be to finesse the specification of this property, perhaps:
> 
> 
>      * <tr><th scope="row">{@systemProperty java.specification.maintenance.version}</th>
>      *     <td>Java Runtime Environment specification maintenance version, which may
>      *         be interpreted as a non-zero integer. If defined, the value of this
>      *         property is the identifying number of the most recent <a
>      *         href="https://jcp.org/en/procedures/jcp2#3.6.4">specification
>      *         maintenance release</a> that required a change to the runtime</a>
>      *         <em>(optional)</em>.
>      *         </td></tr>

In the latest push, to address the concerns raised updated the proposed wording to, in plain text:

Java Runtime Environment specification maintenance version, not defined before the specification implemented by this runtime has undergone a maintenance release (optional). When defined, the value of this property may be interpreted as a positive integer. The value indicates the latest maintenance release the runtime is known to support. A later release may be supported by the environment. To indicate the first maintenance release this property will have the value "1"; to indicate the second maintenance release, this property will have the value "2", and so on.

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

PR: https://git.openjdk.java.net/jdk/pull/8437

From naoto at openjdk.java.net  Mon May  2 21:15:28 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 May 2022 21:15:28 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <pHhXVFBLrw6QMurHClTcHBhNZrntKjfnuCqaPttnxeE=.215ebd9e-c48b-485b-86a8-c5c889b307c2@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <0oFVCJWhQrze7dIhCE5j3VfKkWW-XkW40UduBmB_KiE=.2c75dc1b-415a-4e41-bb9f-5e32dfd7f470@github.com>
 <pHhXVFBLrw6QMurHClTcHBhNZrntKjfnuCqaPttnxeE=.215ebd9e-c48b-485b-86a8-c5c889b307c2@github.com>
Message-ID: <R8hSAXBCVRtQA5DuEnZ_HV69mvgqp5iqL80NgLjVgFE=.4cfdebff-851a-485d-b471-631e9073d188@github.com>

On Sun, 1 May 2022 04:47:09 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> test/jdk/java/lang/System/i18nEnvArg.java line 26:
>> 
>>> 24: /*
>>> 25:  * @test
>>> 26:  * @bug 8285517
>> 
>> If the test should work only on a particular env, should describe here and add `@requires`  tag.
>
> Add "@requires (os.family == "linux")"

Also `@modules jdk.charsets` should be added so that the test should be immediately ignored if it does not have `EUC-JP` charset.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From naoto at openjdk.java.net  Mon May  2 21:15:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 May 2022 21:15:38 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
Message-ID: <VYYSygrTTDEJNPlbdmIiJ-WkUTfALvLwjThqh2sP55U=.46c77e96-37ba-4cc0-bd4d-217bb3f13353@github.com>

On Sun, 1 May 2022 04:51:17 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

test/jdk/java/lang/System/i18nEnvArg.java line 63:

> 61:     }
> 62: 
> 63:     public static class Start {

Do we need `Start` class? Can it be merged with the parent to reduce the complexity?

test/jdk/java/lang/System/i18nEnvArg.java line 87:

> 85:                 System.getProperty("java.class.path"),
> 86:                 "i18nEnvArg$Verify",
> 87:                 EUC_JP_TEXT);

Can utilize `ProcessTools` class.

test/jdk/java/lang/System/i18nEnvArg.java line 130:

> 128:             environ_mid.setAccessible(true);
> 129:             byte[][] environ = (byte[][]) environ_mid.invoke(null,
> 130:                 (Object[])null);

I am not sure I like this piece, invoking a package private method of `ProcessEnvironment` class. Can we simply verify the result of `System.getenv(EUC_JP_TEXT)`?

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From darcy at openjdk.java.net  Mon May  2 23:08:54 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 2 May 2022 23:08:54 GMT
Subject: RFR: JDK-8285977: Add links to IEEE 754 specification
Message-ID: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>

Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard".

Another candidate page to use is

https://ieeexplore.ieee.org/servlet/opac?punumber=8766227

which is (apparently) a stable citation page for the standard.

These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738).

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

Commit messages:
 - JDK-8285977: Add links to IEEE 754 specification

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

PR: https://git.openjdk.java.net/jdk/pull/8511

From jjg at openjdk.java.net  Mon May  2 23:08:54 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 May 2022 23:08:54 GMT
Subject: RFR: JDK-8285977: Add links to IEEE 754 specification
In-Reply-To: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
References: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
Message-ID: <e7nigXqb5EHQVCwKIqNXRgwtTBv-pLf8sj2E483cF-8=.d1cc93fc-200d-4097-82d0-c13b43e1fde5@github.com>

On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard".
> 
> Another candidate page to use is
> 
> https://ieeexplore.ieee.org/servlet/opac?punumber=8766227
> 
> which is (apparently) a stable citation page for the standard.
> 
> These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738).

I endorse the use of a URL with a host-name like `standards.ieee.org`

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8511

From iris at openjdk.java.net  Mon May  2 23:51:23 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 2 May 2022 23:51:23 GMT
Subject: RFR: JDK-8285977: Add links to IEEE 754 specification
In-Reply-To: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
References: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
Message-ID: <LjJ5B7hFzna_ygD2KopYUm6xMMnGUuVuQi1JEfteOwo=.aa2cad2d-109e-4480-8c55-42082959a309@github.com>

On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard".
> 
> Another candidate page to use is
> 
> https://ieeexplore.ieee.org/servlet/opac?punumber=8766227
> 
> which is (apparently) a stable citation page for the standard.
> 
> These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738).

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8511

From dl at openjdk.java.net  Mon May  2 23:58:23 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Mon, 2 May 2022 23:58:23 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v2]
In-Reply-To: <b9yIvjhbR0MBC7plzteME38dHDK6pCPwqvKcl9I5MQA=.b9d6a0f2-21f2-4b01-8c4f-27fca7cd4c7c@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <b9yIvjhbR0MBC7plzteME38dHDK6pCPwqvKcl9I5MQA=.b9d6a0f2-21f2-4b01-8c4f-27fca7cd4c7c@github.com>
Message-ID: <zdcaVUBfz6KmVR2u8fb13H7znpOBAY8xTl9ubQBN8p0=.135fffe0-47ac-4850-87c6-9cd3b67f2f12@github.com>

On Sun, 1 May 2022 14:35:28 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/util/concurrent/FutureTask.java line 222:
> 
>> 220:                 throw new IllegalStateException("Task has not completed");
>> 221:         }
>> 222:     }
> 
> I think the code will be more readable if a switch expression and the arrow syntax are used
> 
> 
> return switch(state()) {
>     case SUCCESS -> {
>         @SuppressWarnings("unchecked")
>         V result = (V) outcome;
>         yield result;
>     } 
>     case FAILED -> throw new IllegalStateException("Task completed with exception");
>     ...
> };

Sorry, I don't understand how it would be more readable. I like new switch features because they extend the range of applicability of switch. But this (and the two others) are just plain vanilla enum-based switches that were handled well, and seem to have the same numbers of lines and structure either way?

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From iris at openjdk.java.net  Mon May  2 23:59:33 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 2 May 2022 23:59:33 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v6]
In-Reply-To: <vYo0UIcyKZGjaQosXWtu_MDG1TPxNz2-Oo2bfEXE_aI=.6cc54504-f465-42be-a8eb-478f9691530a@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <vYo0UIcyKZGjaQosXWtu_MDG1TPxNz2-Oo2bfEXE_aI=.6cc54504-f465-42be-a8eb-478f9691530a@github.com>
Message-ID: <82nYsjc6zoBbNP7HbFHqgGX3B85LgFrC1iNban8q1LE=.15eb982d-7642-428f-a20d-10d0305fc741@github.com>

On Mon, 2 May 2022 20:31:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Update wording to address review feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Change punctuation from review feedback.
>  - Respond to review feedback; make sequence of values explicit.
>  - Respond to review feedback.
>  - Respond to review feedback.
>  - Respond to CSR feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Update comment in template.
>  - JDK-8285497: Add system property for Java SE specification maintenance version

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8437

From bpb at openjdk.java.net  Tue May  3 00:00:22 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 3 May 2022 00:00:22 GMT
Subject: RFR: JDK-8285977: Add links to IEEE 754 specification
In-Reply-To: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
References: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
Message-ID: <By_9ey5U3Dr_uSs1Segyq4BDxlGT0PyRKWt1k6Tsya8=.fbde3630-10c8-4411-a594-d89d063d3d7f@github.com>

On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard".
> 
> Another candidate page to use is
> 
> https://ieeexplore.ieee.org/servlet/opac?punumber=8766227
> 
> which is (apparently) a stable citation page for the standard.
> 
> These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738).

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8511

From darcy at openjdk.java.net  Tue May  3 01:23:20 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 3 May 2022 01:23:20 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v5]
In-Reply-To: <c4xaElUahQKe72pq-zI4MWvWCWObe4oMyV8z89G8GFg=.a7d8d8dd-959c-4a7d-bdc7-227c6db2e550@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
 <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>
 <ComDy6I5wL37EpHF_giwqof4VNkvZzCvexm3SGukzMc=.e476bdd6-12a6-4ae0-9f8d-8dd79a20aaa4@github.com>
 <c4xaElUahQKe72pq-zI4MWvWCWObe4oMyV8z89G8GFg=.a7d8d8dd-959c-4a7d-bdc7-227c6db2e550@github.com>
Message-ID: <xE9BZUJUudGTx8ZyRc9ta46majTcUA20GiGXgkMjMXE=.9c716eb4-a6ca-47a5-addb-4d094ca8f4ec@github.com>

On Mon, 2 May 2022 20:30:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> @irisclark does raise an interesting point: If, say, MR 2 doesn?t require a change to the RI then the MR 1 RI is also the MR 2 RI, but its `java.specification.maintenance.version` property will report that it?s the MR 1 RI.
>> 
>> One way to fix this would be to require an RI update with every MR just to update this property, even if no other code in the RI changes ? but we prefer to avoid doing RI builds unnecessarily.
>> 
>> Another way to fix it would be to finesse the specification of this property, perhaps:
>> 
>> 
>>      * <tr><th scope="row">{@systemProperty java.specification.maintenance.version}</th>
>>      *     <td>Java Runtime Environment specification maintenance version, which may
>>      *         be interpreted as a non-zero integer. If defined, the value of this
>>      *         property is the identifying number of the most recent <a
>>      *         href="https://jcp.org/en/procedures/jcp2#3.6.4">specification
>>      *         maintenance release</a> that required a change to the runtime</a>
>>      *         <em>(optional)</em>.
>>      *         </td></tr>
>
> In the latest push, to address the concerns raised updated the proposed wording to, in plain text:
> 
> Java Runtime Environment specification maintenance version, not defined before the specification implemented by this runtime has undergone a maintenance release (optional). When defined, the value of this property may be interpreted as a positive integer. The value indicates the latest maintenance release the runtime is known to support. A later release may be supported by the environment. To indicate the first maintenance release this property will have the value "1"; to indicate the second maintenance release, this property will have the value "2", and so on.

PS CSR Updated to reflect this push; please review: https://bugs.openjdk.java.net/browse/JDK-8285764

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

PR: https://git.openjdk.java.net/jdk/pull/8437

From jpai at openjdk.java.net  Tue May  3 01:26:23 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 3 May 2022 01:26:23 GMT
Subject: RFR: 8285915: failure_handler: gather the contents of /etc/hosts
 file [v2]
In-Reply-To: <1dGZqNYHArw0QW_tY2GZJ1zbKTRuiI0R3aI7RjTsn8Q=.36ef7f58-0c9c-4aa8-aa67-677ca9774a50@github.com>
References: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
 <1dGZqNYHArw0QW_tY2GZJ1zbKTRuiI0R3aI7RjTsn8Q=.36ef7f58-0c9c-4aa8-aa67-677ca9774a50@github.com>
Message-ID: <GgDLl_Xm8RmsDvpS2oGFkHjyye9uBhZPUzyU_JD1K1I=.a8ab8d6b-09f5-4100-8165-298771d82aa7@github.com>

On Mon, 2 May 2022 06:25:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915?
>> 
>> With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail.
>> 
>> Testing done (on macOS):
>> 
>> 
>> cd test/failure_handler 
>> make test
>> 
>> Then verified that the generated environment.html had the `/etc/hosts` file content
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   print contents of hosts file in windows failure handler

Thank you Erik and Daniel for the reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/8466

From jpai at openjdk.java.net  Tue May  3 01:26:24 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 3 May 2022 01:26:24 GMT
Subject: Integrated: 8285915: failure_handler: gather the contents of
 /etc/hosts file
In-Reply-To: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
References: <BmAHOE3jvk-S4uT088sabC4Jtv9U5HOG9afL74jPSZs=.2d513d03-fb85-4f98-8bda-c2f8c9716175@github.com>
Message-ID: <jxYST4tVTauOis5xT7gvx4gQpToUXr_PBYMvbWQIK_g=.55f700b1-886d-4a16-a99b-356ea4ddf64b@github.com>

On Fri, 29 Apr 2022 11:28:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.java.net/browse/JDK-8285915?
> 
> With this change, the environment details collected by the failure handler will now include the contents of the `/etc/hosts/` file, which can be useful in certain cases when debugging network tests that fail.
> 
> Testing done (on macOS):
> 
> 
> cd test/failure_handler 
> make test
> 
> Then verified that the generated environment.html had the `/etc/hosts` file content

This pull request has now been integrated.

Changeset: 45ca81ff
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45ca81ff5f25ce7927c5debc2f89b41246b91b92
Stats:     13 lines in 3 files changed: 10 ins; 0 del; 3 mod

8285915: failure_handler: gather the contents of /etc/hosts file

Reviewed-by: dfuchs, erikj

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

PR: https://git.openjdk.java.net/jdk/pull/8466

From darcy at openjdk.java.net  Tue May  3 04:34:27 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 3 May 2022 04:34:27 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v18]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <ITWLYPcZR79UX2Hb_jElWjJYbj1is-E390LVkKud0rE=.d07ffa4c-9278-450e-a09f-9f29a4f06779@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

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

 - Implement review feedback from mlchung.
 - Fix type in @throws tag.
 - Merge branch 'master' into JDK-8266670
 - Respond to review feedback.
 - Merge branch 'master' into JDK-8266670
 - Make workding changes suggested in review feedback.
 - Merge branch 'master' into JDK-8266670
 - Typo fix; add implSpec to Executable.
 - Appease jcheck.
 - Fix some bugs found by inspection, docs cleanup.
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/97d4dde5...8a3a3cd8

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7445/files
  - new: https://git.openjdk.java.net/jdk/pull/7445/files/14980605..8a3a3cd8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=16-17

  Stats: 358875 lines in 5512 files changed: 257744 ins; 47741 del; 53390 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.java.net/jdk/pull/7445

From jpai at openjdk.java.net  Tue May  3 05:04:19 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 3 May 2022 05:04:19 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v5]
In-Reply-To: <jzzX1o_WHbLsvrstqOfeTYV7iHkxQbjxlziT1_FVYR0=.7272f1f2-c556-4340-b062-add591d73b68@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <A-3GCS_VCMIfss1czbRd-Dk2mdMuarJs6AjcMX5LpD4=.91358fdc-a47d-48a5-a59d-18a2c2e7b759@github.com>
 <7RAAJPEdgNo3PoeQh8bQiXvr7Hdckya1cjLDt5oweHI=.a6d309e2-7307-4d91-a708-8f70658849ca@github.com>
 <1l_DgR2KfeB1qDNJTeIzCEdEhy1wGTGnxpMUrChRvHo=.fe3bcba6-e120-40ab-b4b3-5db0fa316f48@github.com>
 <jzzX1o_WHbLsvrstqOfeTYV7iHkxQbjxlziT1_FVYR0=.7272f1f2-c556-4340-b062-add591d73b68@github.com>
Message-ID: <stKRgoiMrWRAvFF2K7rUznw9v5jRrLI8BDR_mYNfZgc=.379e3545-ce72-442c-bd3f-013d7a020459@github.com>

On Mon, 2 May 2022 13:13:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> `lines.remove()` and `lines.subList()` will throw the correct exception. Since you asked, we can add it.
>
> Now that we call `subList` at the beginning, I think there's no need to explicitly perform a check.

Hello Weijun, the change to this part of the code in context of index checks, looks fine to me now. Thank you for considering it.

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

PR: https://git.openjdk.java.net/jdk/pull/8360

From mbaesken at openjdk.java.net  Tue May  3 07:04:56 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 3 May 2022 07:04:56 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v2]
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <gcpooE-1UOWliURbx9I_hwF8YrbYa9BYeM7WPrzg1EY=.9bb8e59b-1760-4c77-8bd0-a70469ec4357@github.com>

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

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

  set _WIN32_WINNT=0x0601 centrally in flags-cflags.m4

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8428/files
  - new: https://git.openjdk.java.net/jdk/pull/8428/files/aef2486f..dff223c5

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

  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8428.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428

PR: https://git.openjdk.java.net/jdk/pull/8428

From mbaesken at openjdk.java.net  Tue May  3 07:10:58 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 3 May 2022 07:10:58 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <O91M8nZ3f4LIL_JqrgtCqQ-oDAb7IKptzdRZvoAhI3Y=.8748256a-aaec-47f7-8ba2-79befaedff4a@github.com>

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

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

  Adjust Copyright year in wepoll.c

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8428/files
  - new: https://git.openjdk.java.net/jdk/pull/8428/files/dff223c5..23b63c5b

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

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From forax at openjdk.java.net  Tue May  3 07:19:13 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 3 May 2022 07:19:13 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v2]
In-Reply-To: <zdcaVUBfz6KmVR2u8fb13H7znpOBAY8xTl9ubQBN8p0=.135fffe0-47ac-4850-87c6-9cd3b67f2f12@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <b9yIvjhbR0MBC7plzteME38dHDK6pCPwqvKcl9I5MQA=.b9d6a0f2-21f2-4b01-8c4f-27fca7cd4c7c@github.com>
 <zdcaVUBfz6KmVR2u8fb13H7znpOBAY8xTl9ubQBN8p0=.135fffe0-47ac-4850-87c6-9cd3b67f2f12@github.com>
Message-ID: <PspuFJa6sBoxxPokA-Eqa6cdB6Ac7kyXzDPxx_WWlFY=.d9c3c006-2ec0-4167-892f-114bead1b000@github.com>

On Mon, 2 May 2022 23:54:33 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/FutureTask.java line 222:
>> 
>>> 220:                 throw new IllegalStateException("Task has not completed");
>>> 221:         }
>>> 222:     }
>> 
>> I think the code will be more readable if a switch expression and the arrow syntax are used
>> 
>> 
>> return switch(state()) {
>>     case SUCCESS -> {
>>         @SuppressWarnings("unchecked")
>>         V result = (V) outcome;
>>         yield result;
>>     } 
>>     case FAILED -> throw new IllegalStateException("Task completed with exception");
>>     ...
>> };
>
> Sorry, I don't understand how it would be more readable. I like new switch features because they extend the range of applicability of switch. But this (and the two others) are just plain vanilla enum-based switches that were handled well, and seem to have the same numbers of lines and structure either way?

It's more readable because it's now clear that the aim is to return the value of the switch.
Also a switch expression has to be exhaustive, so there is no need for a 'default'.

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From duke at openjdk.java.net  Tue May  3 08:08:27 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 3 May 2022 08:08:27 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v7]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <0Z-S1bJRG9LAg7iMN9-ze4XKHVeuAhGehSyLMR4kC54=.2fb5660b-6c62-4e07-ba8f-7aba79ab2ad4@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

xpbob has updated the pull request incrementally with three additional commits since the last revision:

 - add test
 - add test
 - add cgroup v1 test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/9dd1bbf3..8c46be1c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=05-06

  Stats: 305 lines in 4 files changed: 268 ins; 36 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From alanb at openjdk.java.net  Tue May  3 08:11:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 3 May 2022 08:11:45 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v10]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <C12QFWDYSwfwhM2JV6cdT5duNy-3F7mmYy9eTCItmtM=.ccd6fb59-f1ee-4cd2-b24f-7d439d636b09@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
 - Merge with jdk-19+19
 - Refresh
 - Refresh
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/cfcba1fc...f41b3131

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=09
  Stats: 102769 lines in 1140 files changed: 92907 ins; 4216 del; 5646 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Tue May  3 08:11:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 3 May 2022 08:11:47 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8]
In-Reply-To: <htZ8N0SehZt8GFsN3GD8d0lvFbFlfjHdLv-PonqMYBI=.79c09d37-e6db-4746-b608-702eeca04539@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TxVRjXSUQihJciCxeQ1kcvsw_Vw15ywxsac12vfwIEY=.28355d2a-a5cb-4eaf-8e35-49fc0cb457ad@github.com>
 <ZIbvg5mqBKnDkPqj_VXglNgLvfgXGoXXQeKkCdXEpog=.222d1b6a-ba31-4b24-8087-8939d91f6b40@github.com>
 <htZ8N0SehZt8GFsN3GD8d0lvFbFlfjHdLv-PonqMYBI=.79c09d37-e6db-4746-b608-702eeca04539@github.com>
Message-ID: <fkmUI64vg-G_ILxioCOP_NqlP2O5LvNK1v9_vj1xvt8=.1e5cef3c-d532-4050-8860-4425d5acd5c2@github.com>

On Mon, 2 May 2022 17:29:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139:
>> 
>>> 137:            thr_info.name,        (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel",
>>> 138:         (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user");
>>> 139:   }
>> 
>> I'd suggest to add locals (their names are up to you):
>>    const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel";
>>    const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user";
>> 
>> It is better to place togeter lines: 129+130.
>> Line 137 is not aligned, and there are many unneeded spaces.
>> The '()' around conditions are not needed. At least, I do not see them increasing readability.
>
> fixed

Thanks, I'll mark all the comments related to the JVMTI event tests as resolved.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Tue May  3 08:13:30 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 3 May 2022 08:13:30 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v8]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <_fR3JdAyP9rRB-L8HF99EikD_qVw_U6AXPQOZR4yc-4=.a255c2b7-520c-40f7-93c7-2779416882ff@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

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

  revert TestMisc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/8c46be1c..13688f1c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=06-07

  Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Tue May  3 08:19:08 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 3 May 2022 08:19:08 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v9]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <A9eJxrdI85CmSC4_jMTN4beAzbmb6j3hWYZM4cCvkts=.372ce097-132b-417b-9bda-e6a59fdca44e@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

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

  remove whitespace

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/13688f1c..f7998d79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/8285

From alanb at openjdk.java.net  Tue May  3 08:27:22 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 3 May 2022 08:27:22 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]
In-Reply-To: <jTYB50MGyVQqaGZ8LsgICew0lkS-GYdN9UCjkKsM0y0=.a14f468d-1d6d-4cad-a012-0f030a5f1313@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <fb6V2fi9al6WD5-n-IlcGF5Iv9Bg1EbphIZGUnVezlQ=.fd40ece0-21ec-42f5-9669-af7cd0f47bb8@github.com>
 <jTYB50MGyVQqaGZ8LsgICew0lkS-GYdN9UCjkKsM0y0=.a14f468d-1d6d-4cad-a012-0f030a5f1313@github.com>
Message-ID: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com>

On Thu, 28 Apr 2022 07:13:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.base/windows/native/libnio/ch/wepoll.c line 159:
>> 
>>> 157: 
>>> 158: #undef _WIN32_WINNT
>>> 159: #define _WIN32_WINNT 0x0601
>> 
>> This is 3rd party code and would prefer not change it if possible.
>
> Hi Alan, I agree (thats why I did not change the define in harfbuzz,  but I missed that wepoll.c is 3rd party code as well).

I assume you can revert the update to the copyright header in the latest version as there aren't any changes to this source file now.

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From duke at openjdk.java.net  Tue May  3 08:28:24 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 3 May 2022 08:28:24 GMT
Subject: RFR: JDK-8285977: Add links to IEEE 754 specification
In-Reply-To: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
References: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
Message-ID: <hiWC0JmRDqJMzzPoShsfHKAq-brhDbCe8lx6ARco354=.5a15aea4-14f5-40b6-b9da-4d2896daee50@github.com>

On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard".
> 
> Another candidate page to use is
> 
> https://ieeexplore.ieee.org/servlet/opac?punumber=8766227
> 
> which is (apparently) a stable citation page for the standard.
> 
> These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738).

What about the DOI URL? Probably even more stable.
https://doi.org/10.1109/IEEESTD.2019.8766229

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

PR: https://git.openjdk.java.net/jdk/pull/8511

From duke at openjdk.java.net  Tue May  3 08:31:21 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 3 May 2022 08:31:21 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v10]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <Uk95k4aLvvcF1_1CPAXzKt_4894lzS4O9EOyfs0ixmo=.8e7519e1-4832-47f2-a2c5-2074c3d01e49@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

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

  remove debug info

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/f7998d79..77676edf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=08-09

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Tue May  3 08:34:50 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 3 May 2022 08:34:50 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v11]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <tgt8QqPDGJk4LNn_p_2cbkqvg7rpQJqt6Tq1brH4c5A=.ca001bac-9920-4785-9936-164f676e975d@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

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

  format code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/77676edf..97a547f4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=09-10

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

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Tue May  3 09:15:30 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 3 May 2022 09:15:30 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v11]
In-Reply-To: <tgt8QqPDGJk4LNn_p_2cbkqvg7rpQJqt6Tq1brH4c5A=.ca001bac-9920-4785-9936-164f676e975d@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <tgt8QqPDGJk4LNn_p_2cbkqvg7rpQJqt6Tq1brH4c5A=.ca001bac-9920-4785-9936-164f676e975d@github.com>
Message-ID: <7qG1WjxLljjUo-7BppmgI-NUnhZwid5VJl55J1RRi-o=.d2fb6f1a-8110-42e7-8d55-4853408dfc72@github.com>

On Tue, 3 May 2022 08:34:50 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   format code

Thanks for review.
@jerboaa 
I added new test cases to run only in cgroupv1 environment

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

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Tue May  3 09:21:11 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 3 May 2022 09:21:11 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v12]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <NbWMj34lBAIvrdaiqmWzK88uGV6F1Ai3paJpPaVW4GQ=.85e23edd-3caa-47bf-8067-f0b20c5be1f7@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

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

  remove no use copy

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/97a547f4..ed2f2855

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=10-11

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

PR: https://git.openjdk.java.net/jdk/pull/8285

From jlahoda at openjdk.java.net  Tue May  3 09:34:45 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 3 May 2022 09:34:45 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v9]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <m_ymLdpAFIEkQR1cjVs3V0JS8IHKpD80IGlN23qJXzI=.099f6b86-7db5-4294-b631-6a229b5b42f6@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into type-patterns-third
 - Reducing MatchException constructors.
 - Merge branch 'master' into type-patterns-third
 - Reference-type pattern is not applicable at a selector of a primitive type - fixing.
 - Merge branch 'master' into type-patterns-third
 - Cleanup, fixing tests.
 - Cleanup - more total -> unconditional pattern renaming.
 - Adjusting to review feedback.
 - Cleanup.
 - Fixing tests.
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...cb5c1d20

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

Changes: https://git.openjdk.java.net/jdk/pull/8182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=08
  Stats: 860 lines in 52 files changed: 424 ins; 244 del; 192 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From Rony.Flatscher at wu.ac.at  Tue May  3 09:59:40 2022
From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher)
Date: Tue, 3 May 2022 11:59:40 +0200
Subject: RFR: JDK-8285977: Add links to IEEE 754 specification
In-Reply-To: <hiWC0JmRDqJMzzPoShsfHKAq-brhDbCe8lx6ARco354=.5a15aea4-14f5-40b6-b9da-4d2896daee50@github.com>
References: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
 <hiWC0JmRDqJMzzPoShsfHKAq-brhDbCe8lx6ARco354=.5a15aea4-14f5-40b6-b9da-4d2896daee50@github.com>
Message-ID: <b0c136bf-2683-b893-4711-f1ee2dfac658@wu.ac.at>

On 03.05.2022 10:28, Raffaello Giulietti wrote:
> On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>> Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard".
>>
>> Another candidate page to use is
>>
>> https://ieeexplore.ieee.org/servlet/opac?punumber=8766227
>>
>> which is (apparently) a stable citation page for the standard.
>>
>> These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738).
> What about the DOI URL? Probably even more stable.
> https://doi.org/10.1109/IEEESTD.2019.8766229
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/8511

Maybe informal links to the resources made available via the web by the IEEE 754 editor, Mike F. Cowlishaw, could be helpful:

- <http://speleotrove.com/decimal/>
- Previous standard: <https://www.iso.org/standard/57469.html> with <http://speleotrove.com/misc/IEEE754-errata.html>
- Current standard: <https://www.iso.org/standard/80985.html> with <http://speleotrove.com/misc/IEEE754-errata-2019.html>

---rony



From mcimadamore at openjdk.java.net  Tue May  3 10:09:36 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 3 May 2022 10:09:36 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v36]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <zBWrOVUAtzKYLgfMs09ANQNpmFvtpRZuyvlAvs6u2ec=.d88f6cfb-ee02-4b99-85dd-b997d39a718e@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Tweak support for Linker lookup
   Improve javadoc of SymbolLookup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/d1fcf012..dc309e8b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=35
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=34-35

  Stats: 159 lines in 14 files changed: 96 ins; 8 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Tue May  3 10:09:38 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 3 May 2022 10:09:38 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v35]
In-Reply-To: <HEhSADkgPhVdl0YLJl-1JdpTnrMlTshuHheXIegomWE=.6e2ae565-5632-4c8f-9fdc-2f20f18e99dc@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <HEhSADkgPhVdl0YLJl-1JdpTnrMlTshuHheXIegomWE=.6e2ae565-5632-4c8f-9fdc-2f20f18e99dc@github.com>
Message-ID: <wwsEntfub0DdNW9FidXoRV5KFsEuUCGj_d300HI4iVw=.d50ef030-6228-49a3-84c0-e7797598bf6a@github.com>

On Fri, 29 Apr 2022 08:15:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak Addressable javadoc

We've tweaked the support for looking up symbols in the standard libraries - `CLinker` used to implement `SymbolLookup`, now `CLinker` returns a "default lookup" instead. We've also greatly improved the javadoc of `SymbolLookup` - many thanks to Alex for the help! New javadoc here:

http://cr.openjdk.java.net/~mcimadamore/8282191/v3/javadoc/java.base/module-summary.html

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Tue May  3 10:40:02 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 3 May 2022 10:40:02 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:

 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Tweak support for Linker lookup
   Improve javadoc of SymbolLookup
 - Tweak Addressable javadoc
 - Downcall and upcall tests use wrong layout which is missing some trailing padding
 - Simplify libraryLookup impl
 - Address CSR comments
 - Merge branch 'master' into foreign-preview
 - Add ValueLayout changes
 - Tweak support for array element var handle
 - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab

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

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=36
  Stats: 65464 lines in 367 files changed: 43470 ins; 19432 del; 2562 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From alanb at openjdk.java.net  Tue May  3 10:59:24 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 3 May 2022 10:59:24 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v2]
In-Reply-To: <6o1i3zFRklC1C7giECN4v8s7591LVoKr5IWX2YkUsOk=.50b90259-d7ac-490e-8534-917362479b1c@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <6o1i3zFRklC1C7giECN4v8s7591LVoKr5IWX2YkUsOk=.50b90259-d7ac-490e-8534-917362479b1c@github.com>
Message-ID: <MMLNUTl96S99BGSqEYCKpHTaAJrQXyOkIpDetttb8S8=.b4ff9297-570e-4f2e-bf41-7ebfe8a3078d@github.com>

On Mon, 2 May 2022 13:33:33 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

I've been testing the ForkJoinPool update for some time and the performance improvements for the FIFO/async-mode for very impressive.

One behavior change from JDK 17/18 is that TLs are now preserved by the threads in the common pool for the no-SM case. This may be observed as "memory leak" in some environments but a help in others.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8490

From sgehwolf at openjdk.java.net  Tue May  3 11:57:32 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 3 May 2022 11:57:32 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v12]
In-Reply-To: <NbWMj34lBAIvrdaiqmWzK88uGV6F1Ai3paJpPaVW4GQ=.85e23edd-3caa-47bf-8067-f0b20c5be1f7@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <NbWMj34lBAIvrdaiqmWzK88uGV6F1Ai3paJpPaVW4GQ=.85e23edd-3caa-47bf-8067-f0b20c5be1f7@github.com>
Message-ID: <jCXmd3qp2siQk7CDS7bWBClJ9bMtCc1r8SCcKFcoRkE=.4f401777-b506-4750-b35e-6376ce14cb49@github.com>

On Tue, 3 May 2022 09:21:11 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove no use copy

To be honest, the original test change was closer to what I was expecting to see. Could you clarify why we'd need to use `cgcreate` et.al. for this test? As far as I'm aware `--memory-swappiness` should work just as well.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 150:

> 148:     GET_CONTAINER_INFO(julong, _memory->controller(), "/memory.swappiness",
> 149:                        "Swappiness is: " JULONG_FORMAT, JULONG_FORMAT, swappiness);
> 150:     if(swappiness == 0) {

Style: Space before `(`

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 152:

> 150:     if(swappiness == 0) {
> 151:       jlong memlimit = read_memory_limit_in_bytes();
> 152:       log_trace(os, container)("Memory and Swap Limit has been reset to " JULONG_FORMAT " because of Swappiness is 0", memlimit);

`s/because of Swappiness is 0/because swappiness is 0/g`

test/hotspot/jtreg/containers/docker/TestCgroupV1Memory.java line 58:

> 56:             try {
> 57:                 testMemoryLimit();
> 58:                 testMemoryLimitWithSwappiness();

Only `testMemoryLimitWithSwappiness()` should be `cgroupv1` conditional.

test/lib/jdk/test/lib/containers/cgroup/CgroupV1TestUtils.java line 34:

> 32: 
> 33: 
> 34: public class CgroupV1TestUtils {

I'm not sure what the point of this class is. Wouldn't we be able to test the same thing with the existing docker infrastructure using `--memory-swappiness=0` as docker option? As far as I can see this utility adds a dependency in `libcgroup` and related tools, which isn't necessarily installed on test systems. Docker dep, on the other hand, is enforced via `@require` tag.

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

Changes requested by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8285

From jlahoda at openjdk.java.net  Tue May  3 12:16:27 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 3 May 2022 12:16:27 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
Message-ID: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>

8262889: Compiler implementation for Record Patterns

A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html

There are two notable tricky parts:
-in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
-in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview

`MatchException` has been extended to cover additional cases related to record patterns.

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

Depends on: https://git.openjdk.java.net/jdk/pull/8182

Commit messages:
 - 8262889: Compiler implementation for Record Patterns

Changes: https://git.openjdk.java.net/jdk/pull/8516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262889
  Stats: 2008 lines in 45 files changed: 1943 ins; 15 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From dfuchs at openjdk.java.net  Tue May  3 12:54:21 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 3 May 2022 12:54:21 GMT
Subject: RFR: 8285452: Add a new test library API to replace a file content
 using FileUtils.java [v9]
In-Reply-To: <HdpX4Sj-YzXVrrXrtP78xKF3zjX02CheXtOhlxagOTY=.3f8489cb-4c44-409e-8c95-3a76cd2a7e41@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
 <HdpX4Sj-YzXVrrXrtP78xKF3zjX02CheXtOhlxagOTY=.3f8489cb-4c44-409e-8c95-3a76cd2a7e41@github.com>
Message-ID: <5tXQbshnUSvN9kBrhs6N3YrVq2YVLyEg6egxOYcNN9c=.5e5076c8-3005-4f32-9406-2385d6e5a3d2@github.com>

On Mon, 2 May 2022 13:01:40 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

>> A new API to support replacing selective lines with desired content.
>
> Sibabrata Sahoo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285452: Tests updated

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8360

From erikj at openjdk.java.net  Tue May  3 13:17:21 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 3 May 2022 13:17:21 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]
In-Reply-To: <O91M8nZ3f4LIL_JqrgtCqQ-oDAb7IKptzdRZvoAhI3Y=.8748256a-aaec-47f7-8ba2-79befaedff4a@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <O91M8nZ3f4LIL_JqrgtCqQ-oDAb7IKptzdRZvoAhI3Y=.8748256a-aaec-47f7-8ba2-79befaedff4a@github.com>
Message-ID: <s5gMz4cqZhx7OvMpPkWKfT80vn3w2ecEnINypftT1Nk=.2af1158b-26a0-4c38-8a28-6184883de93d@github.com>

On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Copyright year in wepoll.c

If we define this centrally using compiler flags, then we should not also update each location in the source. Those need to either be removed or left alone. In the cases where the source definition is guarded with an ifndef and there is a comment explaining why a particular version of windows is required, keeping it around could make sense. But on the other hand, since those defines are overridden using flags, they are likely to bit rot over time so we might as well just remove all of them.

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From dholmes at openjdk.java.net  Tue May  3 13:31:12 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 3 May 2022 13:31:12 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]
In-Reply-To: <O91M8nZ3f4LIL_JqrgtCqQ-oDAb7IKptzdRZvoAhI3Y=.8748256a-aaec-47f7-8ba2-79befaedff4a@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <O91M8nZ3f4LIL_JqrgtCqQ-oDAb7IKptzdRZvoAhI3Y=.8748256a-aaec-47f7-8ba2-79befaedff4a@github.com>
Message-ID: <PIDh6k2k57rpJwLeWy2gBFLx3eYmMlRtzXj7ImR3qPM=.e58bf209-91c1-46ea-a661-a5a6bb7195ba@github.com>

On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Copyright year in wepoll.c

I agree with Erik - the source locations need to be modified to not define it. If we want to keep a record perhaps add an assertion that the value is what was expected?

I still feel we have a disconnect between this and an actual check for what the build and runtime platform version is ...

and it isn't at all clear how someone using an API only in a later Windows version, and so setting _WIN32_WINNT to a higher value, will know that this is defined down in the build files ?

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From duke at openjdk.java.net  Tue May  3 13:34:26 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 3 May 2022 13:34:26 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v13]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <eNv2nAInimyoGJ2iYg6cB1RRHOFDwCyL3W2zH8B-v90=.9f6eb55d-f228-4263-b178-d72eda35b24b@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

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

  update code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/ed2f2855..1be10b57

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=11-12

  Stats: 386 lines in 6 files changed: 118 ins; 265 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Tue May  3 13:38:07 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 3 May 2022 13:38:07 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v14]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <MMSXMDs-bgGHg-v8P7p6DUBK4H-I0nPVXn4eft8ENcQ=.9729e8fb-be7a-4a40-a4f5-0ffe7eb3b2d1@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

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

  revert file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/1be10b57..cd9c195d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=12-13

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Tue May  3 13:42:22 2022
From: duke at openjdk.java.net (xpbob)
Date: Tue, 3 May 2022 13:42:22 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v14]
In-Reply-To: <MMSXMDs-bgGHg-v8P7p6DUBK4H-I0nPVXn4eft8ENcQ=.9729e8fb-be7a-4a40-a4f5-0ffe7eb3b2d1@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <MMSXMDs-bgGHg-v8P7p6DUBK4H-I0nPVXn4eft8ENcQ=.9729e8fb-be7a-4a40-a4f5-0ffe7eb3b2d1@github.com>
Message-ID: <ZwknBPIRH_7NkLfdYcWVH1ewO7BnOpIXs-G8p2OqvtQ=.37c0f31c-fcf0-468f-8367-9e88021f8d4f@github.com>

On Tue, 3 May 2022 13:38:07 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert file

Thanks for review.
@jerboaa
The code has been updated

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

PR: https://git.openjdk.java.net/jdk/pull/8285

From mbaesken at openjdk.java.net  Tue May  3 14:00:21 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 3 May 2022 14:00:21 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]
In-Reply-To: <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <fb6V2fi9al6WD5-n-IlcGF5Iv9Bg1EbphIZGUnVezlQ=.fd40ece0-21ec-42f5-9669-af7cd0f47bb8@github.com>
 <jTYB50MGyVQqaGZ8LsgICew0lkS-GYdN9UCjkKsM0y0=.a14f468d-1d6d-4cad-a012-0f030a5f1313@github.com>
 <61bijpgV4Ieny4ue1laoZWoKzJH7nFLWlaF0ZE1fUJM=.a8a96cc5-ad9e-4e87-b45f-9d92a77731b0@github.com>
Message-ID: <09w3bQ6aE-0lywGwhamYkRZeizTLHpYID7C5dzyuzTc=.44290269-9308-4969-ac52-2f0423883b2b@github.com>

On Tue, 3 May 2022 08:23:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Alan, I agree (thats why I did not change the define in harfbuzz,  but I missed that wepoll.c is 3rd party code as well).
>
> I assume you can revert the update to the copyright header in the latest version as there aren't any changes to this source file now.

Yes sure I did it .

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From sgehwolf at openjdk.java.net  Tue May  3 14:43:18 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 3 May 2022 14:43:18 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v14]
In-Reply-To: <MMSXMDs-bgGHg-v8P7p6DUBK4H-I0nPVXn4eft8ENcQ=.9729e8fb-be7a-4a40-a4f5-0ffe7eb3b2d1@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <MMSXMDs-bgGHg-v8P7p6DUBK4H-I0nPVXn4eft8ENcQ=.9729e8fb-be7a-4a40-a4f5-0ffe7eb3b2d1@github.com>
Message-ID: <qoxEhjjojMKzLorjwvqlAGZlIi463jRuY6SKnsSIFNU=.c2b17514-0762-4d95-916d-e1c41edca9d0@github.com>

On Tue, 3 May 2022 13:38:07 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert file

This looks much better. Thanks!

test/hotspot/jtreg/containers/docker/TestMemoryWithCgroupV1.java line 52:

> 50:             return;
> 51:         }
> 52:         if ("cgroupv1".equals(metrics.getProvider())) {

Consider adding a an `else` clause with something like:
`System.out.println("Memory swappiness not supported with cgroups v2. Test skipped.");`

test/hotspot/jtreg/containers/docker/TestMemoryWithCgroupV1.java line 78:

> 76: 
> 77:         OutputAnalyzer out = Common.run(opts);
> 78:         System.out.println(out.getOutput());

This looks like debug output?

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

PR: https://git.openjdk.java.net/jdk/pull/8285

From martin at openjdk.java.net  Tue May  3 15:36:17 2022
From: martin at openjdk.java.net (Martin Buchholz)
Date: Tue, 3 May 2022 15:36:17 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v2]
In-Reply-To: <6o1i3zFRklC1C7giECN4v8s7591LVoKr5IWX2YkUsOk=.50b90259-d7ac-490e-8534-917362479b1c@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <6o1i3zFRklC1C7giECN4v8s7591LVoKr5IWX2YkUsOk=.50b90259-d7ac-490e-8534-917362479b1c@github.com>
Message-ID: <Xn57UAfX3IeG3fJGF6Upav9Jm16VdJF4XE2L98BZEWw=.8f5268b8-1a96-47ad-bce7-fd16e29db83b@github.com>

On Mon, 2 May 2022 13:33:33 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2153:

> 2151: 
> 2152:     @Override
> 2153:     public Throwable exceptionNow() {

The unwrapping of CompletionExceptions should be documented

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From jason_mehrens at hotmail.com  Tue May  3 16:14:07 2022
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 3 May 2022 16:14:07 +0000
Subject: RFR: 8277090 :  jsr166 refresh for jdk19
In-Reply-To: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
Message-ID: <SJ0PR18MB48814CE58C953592B872476983C09@SJ0PR18MB4881.namprd18.prod.outlook.com>

Hi Doug,

In Future::exceptionNow() and Future::state() I would think we would want to catch CancellationException since the implementation of the Future is not known.  Even though we pre-screen the state I would imagine there could be an implementation that prefers cancellation over normal completion.

For Future::resultNow() and FutureTask::resultNow(), is it intentional that we are not chaining just ExecutionException::getCause() / (Throwable) outcome as the cause of the IllegalStateException?  Chaining that might help with debugging even if that is not how it is suppose to be used.

Jason

________________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Doug Lea <dl at openjdk.java.net>
Sent: Sunday, May 1, 2022 7:29 AM
To: core-libs-dev at openjdk.java.net
Subject: RFR: 8277090 :  jsr166 refresh for jdk19

This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090

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

Commit messages:
 - whitespace
 - sync with loom
 - 8276202: LogFileOutput.invalid_file_vm asserts when being executed from a read only working directory
 - 8284981: Support the vectorization of some counting-down loops in SLP
 - 8284992: Fix misleading Vector API doc for LSHR operator
 - 8254759: [TEST_BUG] [macosx] javax/swing/JInternalFrame/4202966/IntFrameCoord.html fails
 - 8285945: [BACKOUT] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities
 - 8284331: Add sanity check for signal handler modification warning.
 - 8285773: Replace Algorithms.eatMemory(...) with WB.fullGC() in vmTestbase/gc/gctests/ReferencesGC/ReferencesGC.java
 - 8284883: JVM crash: guarantee(sect->end() <= sect->limit()) failed: sanity on AVX512
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/3d07b3c7...501a21e8

Changes: https://git.openjdk.java.net/jdk/pull/8490/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8490&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277090
  Stats: 3750 lines in 30 files changed: 2060 ins; 656 del; 1034 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8490.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8490/head:pull/8490

PR: https://git.openjdk.java.net/jdk/pull/8490

From joe.darcy at oracle.com  Tue May  3 16:38:31 2022
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 3 May 2022 09:38:31 -0700
Subject: RFR: JDK-8285977: Add links to IEEE 754 specification
In-Reply-To: <b0c136bf-2683-b893-4711-f1ee2dfac658@wu.ac.at>
References: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
 <hiWC0JmRDqJMzzPoShsfHKAq-brhDbCe8lx6ARco354=.5a15aea4-14f5-40b6-b9da-4d2896daee50@github.com>
 <b0c136bf-2683-b893-4711-f1ee2dfac658@wu.ac.at>
Message-ID: <9825aa2c-aeff-6629-1e1c-ea5206b2198a@oracle.com>

Hello,

While informative, I think some kind of official link to the IEEE 754 
document is more appropriate in this context.

-Joe

On 5/3/2022 2:59 AM, Rony G. Flatscher wrote:
> On 03.05.2022 10:28, Raffaello Giulietti wrote:
>> On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>>
>>> Please review the addition of @-see links from classes that mention 
>>> the IEEE 754 floating-point standard to an IEEE page about the 
>>> standard. The URL in the initial version of the PR is the top search 
>>> result on the IEEE home page for "754 standard".
>>>
>>> Another candidate page to use is
>>>
>>> https://ieeexplore.ieee.org/servlet/opac?punumber=8766227
>>>
>>> which is (apparently) a stable citation page for the standard.
>>>
>>> These links may be upgraded to the the forthcoming @-spec facility 
>>> in the future. ( JDK-6251738).
>> What about the DOI URL? Probably even more stable.
>> https://doi.org/10.1109/IEEESTD.2019.8766229
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/8511
>
> Maybe informal links to the resources made available via the web by 
> the IEEE 754 editor, Mike F. Cowlishaw, could be helpful:
>
> - <http://speleotrove.com/decimal/>
> - Previous standard: <https://www.iso.org/standard/57469.html> with 
> <http://speleotrove.com/misc/IEEE754-errata.html>
> - Current standard: <https://www.iso.org/standard/80985.html> with 
> <http://speleotrove.com/misc/IEEE754-errata-2019.html>
>
> ---rony
>
>

From darcy at openjdk.java.net  Tue May  3 17:00:00 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 3 May 2022 17:00:00 GMT
Subject: RFR: JDK-8285977: Add links to IEEE 754 specification [v2]
In-Reply-To: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
References: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
Message-ID: <Fg8q6k0p_Nu6-991e2H9ilIObKclgzQuQW-7Z6QmhfE=.dd036248-f734-4181-8654-09fe8b564dd3@github.com>

> Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard".
> 
> Another candidate page to use is
> 
> https://ieeexplore.ieee.org/servlet/opac?punumber=8766227
> 
> which is (apparently) a stable citation page for the standard.
> 
> These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738).

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

  Update copyright.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8511/files
  - new: https://git.openjdk.java.net/jdk/pull/8511/files/244fe910..1d9e1521

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

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

PR: https://git.openjdk.java.net/jdk/pull/8511

From darcy at openjdk.java.net  Tue May  3 17:00:01 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 3 May 2022 17:00:01 GMT
Subject: RFR: JDK-8285977: Add links to IEEE 754 specification
In-Reply-To: <hiWC0JmRDqJMzzPoShsfHKAq-brhDbCe8lx6ARco354=.5a15aea4-14f5-40b6-b9da-4d2896daee50@github.com>
References: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
 <hiWC0JmRDqJMzzPoShsfHKAq-brhDbCe8lx6ARco354=.5a15aea4-14f5-40b6-b9da-4d2896daee50@github.com>
Message-ID: <3PBt64yGrl8Q9F8Qhw7185OWXUCeI-GX-zV17BSucmA=.0e41eac9-7199-4310-9eea-f6baa60ba50e@github.com>

On Tue, 3 May 2022 08:25:30 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> What about the DOI URL? Probably even more stable. https://doi.org/10.1109/IEEESTD.2019.8766229

Hmm. I'd rather use the IEEE URL for now; if that turns out to problematic, we can switch to the DOI one.

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

PR: https://git.openjdk.java.net/jdk/pull/8511

From duke at openjdk.java.net  Tue May  3 17:00:01 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 3 May 2022 17:00:01 GMT
Subject: RFR: JDK-8285977: Add links to IEEE 754 specification
In-Reply-To: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
References: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
Message-ID: <mfmdAPDNwwDV1qKQkCObwrzpX8AdDfb9WQe0jAEyG5M=.963ab29b-132f-4455-8e5c-d4140cfdd5fb@github.com>

On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard".
> 
> Another candidate page to use is
> 
> https://ieeexplore.ieee.org/servlet/opac?punumber=8766227
> 
> which is (apparently) a stable citation page for the standard.
> 
> These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738).

The DOI URL currently brings you to exactly the same IEEExplore page.

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

PR: https://git.openjdk.java.net/jdk/pull/8511

From darcy at openjdk.java.net  Tue May  3 17:01:13 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 3 May 2022 17:01:13 GMT
Subject: Integrated: JDK-8285977: Add links to IEEE 754 specification
In-Reply-To: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
References: <8eA6E6SndZ436x_XN0rURKPPtP1I0k04VgTlMIywLGk=.e9bd17d3-0714-4085-9279-9a0dd9f54b48@github.com>
Message-ID: <9BpxPqTGLbMwRJ7ZRTddzoOTjjPgY-MnCi0O5iom_jc=.2b3241d1-4943-4857-8660-dbf16ceaf271@github.com>

On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard".
> 
> Another candidate page to use is
> 
> https://ieeexplore.ieee.org/servlet/opac?punumber=8766227
> 
> which is (apparently) a stable citation page for the standard.
> 
> These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738).

This pull request has now been integrated.

Changeset: 3cbf769f
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3cbf769f55ed9f1837e6417db97bce9597701229
Stats:     22 lines in 7 files changed: 21 ins; 0 del; 1 mod

8285977: Add links to IEEE 754 specification

Reviewed-by: jjg, iris, bpb

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

PR: https://git.openjdk.java.net/jdk/pull/8511

From itakiguchi at openjdk.java.net  Tue May  3 17:12:14 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 3 May 2022 17:12:14 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v3]
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <xl2c_8DML8VRzgn2swE2dOmvxWarH4GMXXA3bXOZ6bw=.017d7c2d-06fd-47bf-9981-6705b6446690@github.com>

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

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

  8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8378/files
  - new: https://git.openjdk.java.net/jdk/pull/8378/files/050dd663..9db79874

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

  Stats: 156 lines in 5 files changed: 83 ins; 50 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8378/head:pull/8378

PR: https://git.openjdk.java.net/jdk/pull/8378

From Alan.Bateman at oracle.com  Tue May  3 17:29:19 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 3 May 2022 18:29:19 +0100
Subject: RFR: 8277090 : jsr166 refresh for jdk19
In-Reply-To: <SJ0PR18MB48814CE58C953592B872476983C09@SJ0PR18MB4881.namprd18.prod.outlook.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <SJ0PR18MB48814CE58C953592B872476983C09@SJ0PR18MB4881.namprd18.prod.outlook.com>
Message-ID: <93b10105-5d53-66cc-ae17-00dd0790305b@oracle.com>

On 03/05/2022 17:14, Jason Mehrens wrote:
> Hi Doug,
>
> In Future::exceptionNow() and Future::state() I would think we would want to catch CancellationException since the implementation of the Future is not known.  Even though we pre-screen the state I would imagine there could be an implementation that prefers cancellation over normal completion.
Is this a Future implementation that doesn't implement the spec 
correctly? The get method shouldn't throw CancellationException if done 
and not-cancelled.


> For Future::resultNow() and FutureTask::resultNow(), is it intentional that we are not chaining just ExecutionException::getCause() / (Throwable) outcome as the cause of the IllegalStateException?  Chaining that might help with debugging even if that is not how it is suppose to be used.
The intention is that ISE means a coding error. The usage of these 
methods should be very close to the test for the state so I think it's 
right as it is. If you set the cause then it be caught and used like a 
CompletionException.

-Alan

From itakiguchi at openjdk.java.net  Tue May  3 17:34:21 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 3 May 2022 17:34:21 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
 <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
Message-ID: <MabGp1p1wQakbe2qEidqR37DYFxQf0FJ8ecxymuhMYs=.8c2d8318-1dea-4bd5-bc76-9649a143d389@github.com>

On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> Can you clarify the use of different charset properties for the ProcessEnvironment vs the CommandLine strings?
> 
> They are used to decode or encode strings in the APIs to native functions respectively.
> If I understand `native.encoding` was introduced to reflect the default encoding of file contents, while `sun.jnu.encoding` is used to encode filenames.
> 
> I think I would have expected to see `sun.jnu.encoding` to be used in all contexts when encoding/decoding strings to the native representations.  (Assuming its not required for backward compatibility).

Hello @RogerRiggs  and @naotoj .

I put new testcase.
I'm not sure, it's expected one...

During my code changes, SecurityManager related testcases were failed.
I'm not sure I can use `System.getProperty("sun.jnu.encoding")` or not. 
So I put SecurityManager related code.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From itakiguchi at openjdk.java.net  Tue May  3 17:34:22 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 3 May 2022 17:34:22 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <VYYSygrTTDEJNPlbdmIiJ-WkUTfALvLwjThqh2sP55U=.46c77e96-37ba-4cc0-bd4d-217bb3f13353@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
 <VYYSygrTTDEJNPlbdmIiJ-WkUTfALvLwjThqh2sP55U=.46c77e96-37ba-4cc0-bd4d-217bb3f13353@github.com>
Message-ID: <8x4pchySckZ09mR3MFAq3hdgwu1IHIV3crYAnDNc-30=.c3405f65-f80c-4974-bb68-be5042e7a945@github.com>

On Mon, 2 May 2022 20:50:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> test/jdk/java/lang/System/i18nEnvArg.java line 63:
> 
>> 61:     }
>> 62: 
>> 63:     public static class Start {
> 
> Do we need `Start` class? Can it be merged with the parent to reduce the complexity?

I'm not sure, it expected one...

I created i18nEnvArg.sh for start-up, then add `@modules jdk.charsets` and remove `i18nEnvArg$Start` class.

> test/jdk/java/lang/System/i18nEnvArg.java line 87:
> 
>> 85:                 System.getProperty("java.class.path"),
>> 86:                 "i18nEnvArg$Verify",
>> 87:                 EUC_JP_TEXT);
> 
> Can utilize `ProcessTools` class.

Use `ProcessTools`

> test/jdk/java/lang/System/i18nEnvArg.java line 130:
> 
>> 128:             environ_mid.setAccessible(true);
>> 129:             byte[][] environ = (byte[][]) environ_mid.invoke(null,
>> 130:                 (Object[])null);
> 
> I am not sure I like this piece, invoking a package private method of `ProcessEnvironment` class. Can we simply verify the result of `System.getenv(EUC_JP_TEXT)`?

I think 3 processes required for this testing.
1. Start test process on ja_JP.eucjp locale
2. Set the test data by encoder
3. Verify the encoded data by decoder

To verify the encoded data, I think I need to check the byte data.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From rriggs at openjdk.java.net  Tue May  3 18:10:08 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 3 May 2022 18:10:08 GMT
Subject: RFR: 8272352: Java launcher can not parse Chinese character when
 system locale is set to UTF-8
In-Reply-To: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
References: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
Message-ID: <vSwhtIhlX2qgbb1_Fz6DijIVBTtjhYX_vqMm7LBPomc=.722aa076-dc65-4695-a052-8bdcf76e1a1e@github.com>

On Wed, 27 Apr 2022 20:23:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Java runtime has been detecting the Windows system locale encoding using `GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...)`, but it returns the *legacy* ANSI code page value, e.g, 1252 for US-English. In order to detect whether the user has selected `UTF-8` as the default, the code page has to be queried with `GetACP()`.
> Also, the case if the call to `GetLocaleInfo` fails changed to fall back to `UTF-8` instead of `Cp1252`.

src/java.base/windows/native/libjava/java_props_md.c line 695:

> 693:                            &display_encoding);
> 694: 
> 695:             sprops.sun_jnu_encoding = getEncodingInternal(0);

How should NULL from `getEncodingInternal` be handled?  (only if malloc fails).
Perhaps just it should return the literal "UTF-8".

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

PR: https://git.openjdk.java.net/jdk/pull/8434

From naoto at openjdk.java.net  Tue May  3 18:39:07 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 3 May 2022 18:39:07 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <8x4pchySckZ09mR3MFAq3hdgwu1IHIV3crYAnDNc-30=.c3405f65-f80c-4974-bb68-be5042e7a945@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
 <VYYSygrTTDEJNPlbdmIiJ-WkUTfALvLwjThqh2sP55U=.46c77e96-37ba-4cc0-bd4d-217bb3f13353@github.com>
 <8x4pchySckZ09mR3MFAq3hdgwu1IHIV3crYAnDNc-30=.c3405f65-f80c-4974-bb68-be5042e7a945@github.com>
Message-ID: <SBEaTIxobl1WdeIzFzVEIJ7y-OA8SduR2gsBGmzWcbo=.eff47757-1377-4916-bd77-db3b70514615@github.com>

On Tue, 3 May 2022 17:30:34 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> test/jdk/java/lang/System/i18nEnvArg.java line 63:
>> 
>>> 61:     }
>>> 62: 
>>> 63:     public static class Start {
>> 
>> Do we need `Start` class? Can it be merged with the parent to reduce the complexity?
>
> I'm not sure, it expected one...
> 
> I created i18nEnvArg.sh for start-up, then add `@modules jdk.charsets` and remove `i18nEnvArg$Start` class.

Sorry if my comment was unclear. I meant to not create a shell script (shell scripts in the test are discouraged), but to re-use the main class twice, invoking with different arguments to main(), as both creating a testJvm process (one for eucjp jvm, and the other for Start).

>> test/jdk/java/lang/System/i18nEnvArg.java line 130:
>> 
>>> 128:             environ_mid.setAccessible(true);
>>> 129:             byte[][] environ = (byte[][]) environ_mid.invoke(null,
>>> 130:                 (Object[])null);
>> 
>> I am not sure I like this piece, invoking a package private method of `ProcessEnvironment` class. Can we simply verify the result of `System.getenv(EUC_JP_TEXT)`?
>
> I think 3 processes required for this testing.
> 1. Start test process on ja_JP.eucjp locale
> 2. Set the test data by encoder
> 3. Verify the encoded data by decoder
> 
> To verify the encoded data, I think I need to check the byte data.

Do we need to verify the intermediate byte encoding? Could we simply compare the text given to environ.put() in Start process and System.getenv() in Verify process match?

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From naoto at openjdk.java.net  Tue May  3 18:55:52 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 3 May 2022 18:55:52 GMT
Subject: RFR: 8272352: Java launcher can not parse Chinese character when
 system locale is set to UTF-8 [v2]
In-Reply-To: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
References: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
Message-ID: <ZvubpWKgDkV_sWE1YGetOND_xyPFqRBrmO2ezDjudBk=.f55cc1de-d9e3-4d76-b848-9037d9a782ca@github.com>

> Java runtime has been detecting the Windows system locale encoding using `GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...)`, but it returns the *legacy* ANSI code page value, e.g, 1252 for US-English. In order to detect whether the user has selected `UTF-8` as the default, the code page has to be queried with `GetACP()`.
> Also, the case if the call to `GetLocaleInfo` fails changed to fall back to `UTF-8` instead of `Cp1252`.

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

  Default to UTF-8 if malloc fails

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8434/files
  - new: https://git.openjdk.java.net/jdk/pull/8434/files/cde671cf..e04e0fb6

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

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8434.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8434/head:pull/8434

PR: https://git.openjdk.java.net/jdk/pull/8434

From naoto at openjdk.java.net  Tue May  3 18:55:55 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 3 May 2022 18:55:55 GMT
Subject: RFR: 8272352: Java launcher can not parse Chinese character when
 system locale is set to UTF-8 [v2]
In-Reply-To: <vSwhtIhlX2qgbb1_Fz6DijIVBTtjhYX_vqMm7LBPomc=.722aa076-dc65-4695-a052-8bdcf76e1a1e@github.com>
References: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
 <vSwhtIhlX2qgbb1_Fz6DijIVBTtjhYX_vqMm7LBPomc=.722aa076-dc65-4695-a052-8bdcf76e1a1e@github.com>
Message-ID: <Jj2upOlDSQmsXlyeFAWiA8E-RGIihgI2J9HIg3rt63s=.f7f479fd-43e6-4417-a556-b7f79f8e6d93@github.com>

On Tue, 3 May 2022 16:17:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Default to UTF-8 if malloc fails
>
> src/java.base/windows/native/libjava/java_props_md.c line 695:
> 
>> 693:                            &display_encoding);
>> 694: 
>> 695:             sprops.sun_jnu_encoding = getEncodingInternal(0);
> 
> How should NULL from `getEncodingInternal` be handled?  (only if malloc fails).
> Perhaps just it should return the literal "UTF-8".

Fixed as suggested.

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

PR: https://git.openjdk.java.net/jdk/pull/8434

From psandoz at openjdk.java.net  Tue May  3 20:23:07 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 3 May 2022 20:23:07 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v2]
In-Reply-To: <6o1i3zFRklC1C7giECN4v8s7591LVoKr5IWX2YkUsOk=.50b90259-d7ac-490e-8534-917362479b1c@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <6o1i3zFRklC1C7giECN4v8s7591LVoKr5IWX2YkUsOk=.50b90259-d7ac-490e-8534-917362479b1c@github.com>
Message-ID: <z_A_dnqJyZuSvLyh_sJorHd8iFqn3jRpOH5XsPOMMA8=.81323e02-558a-456c-a2df-76e6810ae90c@github.com>

On Mon, 2 May 2022 13:33:33 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good, although I cannot say i reviewed the fork join pool code as thoroughly, since it is particularly difficult, so i was most looking for consistency in the pattern of code.

src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java line 76:

> 74:     ForkJoinWorkerThread(ThreadGroup group, ForkJoinPool pool,
> 75:                          boolean useSystemClassLoader,
> 76:                          boolean clearThreadLocals) {

It's tempting to toggle the sense of last boolean argument to be `preserveThreadLocals` for consistency (given the multiple toggles as the value is propagated from the newly added protected constructor), but which means toggling the value at the use sites that you may not wish to change.

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

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8490

From psandoz at openjdk.java.net  Tue May  3 20:23:08 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 3 May 2022 20:23:08 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v2]
In-Reply-To: <Xn57UAfX3IeG3fJGF6Upav9Jm16VdJF4XE2L98BZEWw=.8f5268b8-1a96-47ad-bce7-fd16e29db83b@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <6o1i3zFRklC1C7giECN4v8s7591LVoKr5IWX2YkUsOk=.50b90259-d7ac-490e-8534-917362479b1c@github.com>
 <Xn57UAfX3IeG3fJGF6Upav9Jm16VdJF4XE2L98BZEWw=.8f5268b8-1a96-47ad-bce7-fd16e29db83b@github.com>
Message-ID: <hcpTVtm9cng9sIfxCmXlAPCVzqMNF6-pV3dFRKu0R_A=.e86dec28-235a-4217-a47f-89c1aeb66595@github.com>

On Tue, 3 May 2022 15:32:27 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2153:
> 
>> 2151: 
>> 2152:     @Override
>> 2153:     public Throwable exceptionNow() {
> 
> The unwrapping of CompletionExceptions should be documented

`exceptionNow` is specified to call `get`, which does not throw `CompletionException`:

     * @implSpec
     * The default implementation invokes {@code isDone()} to test if the task
     * has completed. If done and not cancelled, it invokes {@code get()} and
     * catches the {@code ExecutionException} to obtain the exception.

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From jason_mehrens at hotmail.com  Tue May  3 20:44:47 2022
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 3 May 2022 20:44:47 +0000
Subject: RFR: 8277090 : jsr166 refresh for jdk19
In-Reply-To: <93b10105-5d53-66cc-ae17-00dd0790305b@oracle.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <SJ0PR18MB48814CE58C953592B872476983C09@SJ0PR18MB4881.namprd18.prod.outlook.com>
 <93b10105-5d53-66cc-ae17-00dd0790305b@oracle.com>
Message-ID: <SJ0PR18MB48818E8E28762E0C65662DBD83C09@SJ0PR18MB4881.namprd18.prod.outlook.com>

Hi Alan,

>Is this a Future implementation that doesn't implement the spec
>correctly? The get method shouldn't throw CancellationException if done
>and not-cancelled.

What you say makes sense.  I should have checked this before I brought it up but CancellationException is an IllegalStateException so even if it did throw CE it is compliant with the docs.


>The intention is that ISE means a coding error. The usage of these
>methods should be very close to the test for the state so I think it's
>right as it is. If you set the cause then it be caught and used like a
>CompletionException.

Bugs sometimes cause other bugs and dropping the chain can hide that information about a root problem.  I understand the reluctance to add the cause.

Thanks!

Jason

From darcy at openjdk.java.net  Tue May  3 21:35:48 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 3 May 2022 21:35:48 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v19]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <KarZng8o7H5bPfvRdG5L__rxnzB0etngvUrGY_D37rY=.178edfdc-2332-4e41-a702-d43743be6a1c@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

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

  Add mask values to constants' javadoc.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7445/files
  - new: https://git.openjdk.java.net/jdk/pull/7445/files/8a3a3cd8..ead5911f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=17-18

  Stats: 46 lines in 1 file changed: 23 ins; 0 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.java.net/jdk/pull/7445

From darcy at openjdk.java.net  Tue May  3 21:35:49 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 3 May 2022 21:35:49 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v17]
In-Reply-To: <e-Cn_VlPZaymi0QEGmcBN2pRLOuOTopxpKbuBQ1W4UI=.5c48f7f1-bdb6-4616-827e-d1a05960e5c3@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <xrxEt4Nvelbwp2-m2rPYnOwVNlSaConFEnI_PoC2pfQ=.65622250-c913-4dd9-9e74-27b721f08bc9@github.com>
 <e-Cn_VlPZaymi0QEGmcBN2pRLOuOTopxpKbuBQ1W4UI=.5c48f7f1-bdb6-4616-827e-d1a05960e5c3@github.com>
Message-ID: <uD_aEv5Z3lzRg2UtQUuiSFtS6SLI3bcoj09Sbqw4v1c=.1d2705ac-e556-46bf-bcc2-c4da0d1a9f38@github.com>

On Fri, 29 Apr 2022 20:34:21 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I took a closer look at the proposed APIs. I think it's in a good state to target for 19. I skimmed on the existing JDK usage of `getModifiers` other than a trivial test e.g. is public, final, etc and the proposed API works well (btw no plan to convert them and just use those cases for validation).
> 
> The value of `ACC_SUPER` and `ACC_STRICT` could possibly be reused for new access flags. It may be useful to document when the flag becomes obsolete.
> 
> Nit: the enum constants are listed in the order of the mask value, which I like. Some enum constants reference the `Modifer` constants but I think it'd help to see the mask value here consistently for all entries. One go-to place in the source if I want to find the value of different flags.

I've pushed a changeset to add the mask values to the constants' javadoc. Following a don't-repeat-yourself approach, I would have preferred to do this with a @-value tage using the java.lang.reflect.Modifier value (where available), but the @-value tags doesn't seem to offer any formatting so I added the values separately.

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

PR: https://git.openjdk.java.net/jdk/pull/7445

From dl at openjdk.java.net  Tue May  3 22:55:06 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Tue, 3 May 2022 22:55:06 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v2]
In-Reply-To: <z_A_dnqJyZuSvLyh_sJorHd8iFqn3jRpOH5XsPOMMA8=.81323e02-558a-456c-a2df-76e6810ae90c@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <6o1i3zFRklC1C7giECN4v8s7591LVoKr5IWX2YkUsOk=.50b90259-d7ac-490e-8534-917362479b1c@github.com>
 <z_A_dnqJyZuSvLyh_sJorHd8iFqn3jRpOH5XsPOMMA8=.81323e02-558a-456c-a2df-76e6810ae90c@github.com>
Message-ID: <2Rh2V-Lbk-7SODVZb9rX9FsMEEYT3tBAfvZ9pUeO4v0=.edf0a447-6470-4538-b141-12a5f49b0b03@github.com>

On Tue, 3 May 2022 20:00:52 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java line 76:
> 
>> 74:     ForkJoinWorkerThread(ThreadGroup group, ForkJoinPool pool,
>> 75:                          boolean useSystemClassLoader,
>> 76:                          boolean clearThreadLocals) {
> 
> It's tempting to toggle the sense of last boolean argument to be `preserveThreadLocals` for consistency (given the multiple toggles as the value is propagated from the newly added protected constructor), but which means toggling the value at the use sites that you may not wish to change.

Thanks. I changed param name to clearThreadLocals, which I think helps. I do need (only) one negation somewhere along these paths because internally clearing requires a set config bit.

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From dl at openjdk.java.net  Tue May  3 23:10:44 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Tue, 3 May 2022 23:10:44 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v3]
In-Reply-To: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
Message-ID: <JvRq6Fr1LSAgXBOjVfD1J_zm4vdmuib0YCobgi58iak=.01f0eb57-5beb-4a43-a9b7-ec666f6725bb@github.com>

> This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090

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

  Fix internal doc typos; thanks to Martin for finding these.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8490/files
  - new: https://git.openjdk.java.net/jdk/pull/8490/files/c3901b45..76cbde86

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

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From dl at openjdk.java.net  Tue May  3 23:12:53 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Tue, 3 May 2022 23:12:53 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v2]
In-Reply-To: <hcpTVtm9cng9sIfxCmXlAPCVzqMNF6-pV3dFRKu0R_A=.e86dec28-235a-4217-a47f-89c1aeb66595@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <6o1i3zFRklC1C7giECN4v8s7591LVoKr5IWX2YkUsOk=.50b90259-d7ac-490e-8534-917362479b1c@github.com>
 <Xn57UAfX3IeG3fJGF6Upav9Jm16VdJF4XE2L98BZEWw=.8f5268b8-1a96-47ad-bce7-fd16e29db83b@github.com>
 <hcpTVtm9cng9sIfxCmXlAPCVzqMNF6-pV3dFRKu0R_A=.e86dec28-235a-4217-a47f-89c1aeb66595@github.com>
Message-ID: <lp6eCU111w1a2DhrxPyaTK0i3kHMyWpAs017Df-Ew7Q=.48040cb4-725e-4499-8702-7e73e4c59d77@github.com>

On Tue, 3 May 2022 20:04:48 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/CompletableFuture.java line 2153:
>> 
>>> 2151: 
>>> 2152:     @Override
>>> 2153:     public Throwable exceptionNow() {
>> 
>> The unwrapping of CompletionExceptions should be documented
>
> `exceptionNow` is specified to call `get`, which does not throw `CompletionException`:
> 
>      * @implSpec
>      * The default implementation invokes {@code isDone()} to test if the task
>      * has completed. If done and not cancelled, it invokes {@code get()} and
>      * catches the {@code ExecutionException} to obtain the exception.

As (almost) mentioned by others, this is legal because CompletionException is a RuntimeException, and would not be unexpected by CompletableFuture users. (The rules for when it is used have a designed-by-committee feel, because they were!)

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From duke at openjdk.java.net  Wed May  4 01:37:27 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 4 May 2022 01:37:27 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v15]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <QBPcPVkHSe9Q0n8rRgamgLg3XJ8trPcC3X5TK2YlpbU=.0ded1300-8d9e-4318-8b58-a9e60ea6dbc6@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

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

  update code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/cd9c195d..abd5a2b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=13-14

  Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Wed May  4 01:37:27 2022
From: duke at openjdk.java.net (xpbob)
Date: Wed, 4 May 2022 01:37:27 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v14]
In-Reply-To: <MMSXMDs-bgGHg-v8P7p6DUBK4H-I0nPVXn4eft8ENcQ=.9729e8fb-be7a-4a40-a4f5-0ffe7eb3b2d1@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <MMSXMDs-bgGHg-v8P7p6DUBK4H-I0nPVXn4eft8ENcQ=.9729e8fb-be7a-4a40-a4f5-0ffe7eb3b2d1@github.com>
Message-ID: <iz-e_uQgv5slyrscYPtlPjEpZ4NHaY02WT7XvVqBJHI=.0309c395-6922-4dfa-ba69-c8e9d0308cf5@github.com>

On Tue, 3 May 2022 13:38:07 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert file

Thanks for review.
@jerboaa 
The code has been updated

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

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Wed May  4 02:06:01 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 4 May 2022 02:06:01 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
Message-ID: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>

Hi,

This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64

1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from

    ucomiss xmm0, xmm0
    jp      label
    jne     label

into

    ucomiss xmm0, xmm0
    jp      label

2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as

        xorl    ecx, ecx
        ucomiss xmm0, xmm1
        jnp     done
        pushf
        andq    [rsp], 0xffffff2b
        popf
    done:
        movl    eax, 1
        cmovenl eax, ecx

The patch changes this sequence into

    xorl    ecx, ecx
    ucomiss xmm0, xmm1
    movl    eax, 1
    cmovpl  eax, ecx
    cmovnel eax, ecx

3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.

The benchmark results are as follow:

    Before:
    Benchmark                      Mode  Cnt     Score     Error  Units
    FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  ns/op
    FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  ns/op
    FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  ns/op
    FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  ns/op
    FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  ns/op
    FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  ns/op
    FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  ns/op
    FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  ns/op

    After:
    Benchmark                      Mode  Cnt     Score     Error  Units
    FPComparison.equalDouble       avgt    5   594.636 ?   8.922  ns/op
    FPComparison.equalFloat        avgt    5   663.849 ?   3.656  ns/op
    FPComparison.isFiniteDouble    avgt    5   518.309 ? 107.352  ns/op
    FPComparison.isFiniteFloat     avgt    5   515.576 ?  14.669  ns/op
    FPComparison.isInfiniteDouble  avgt    5   621.185 ?  11.935  ns/op
    FPComparison.isInfiniteFloat   avgt    5   623.566 ?  15.206  ns/op
    FPComparison.isNanDouble       avgt    5   400.124 ?   0.762  ns/op
    FPComparison.isNanFloat        avgt    5   546.486 ?   1.509  ns/op

Thank you very much.

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

Commit messages:
 - fix tests
 - test
 - improve infinity
 - remove expensive rules
 - improve fp comparison

Changes: https://git.openjdk.java.net/jdk/pull/8525/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8525&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285973
  Stats: 657 lines in 8 files changed: 569 ins; 70 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8525.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8525/head:pull/8525

PR: https://git.openjdk.java.net/jdk/pull/8525

From itakiguchi at openjdk.java.net  Wed May  4 03:04:16 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 4 May 2022 03:04:16 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <SBEaTIxobl1WdeIzFzVEIJ7y-OA8SduR2gsBGmzWcbo=.eff47757-1377-4916-bd77-db3b70514615@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
 <VYYSygrTTDEJNPlbdmIiJ-WkUTfALvLwjThqh2sP55U=.46c77e96-37ba-4cc0-bd4d-217bb3f13353@github.com>
 <8x4pchySckZ09mR3MFAq3hdgwu1IHIV3crYAnDNc-30=.c3405f65-f80c-4974-bb68-be5042e7a945@github.com>
 <SBEaTIxobl1WdeIzFzVEIJ7y-OA8SduR2gsBGmzWcbo=.eff47757-1377-4916-bd77-db3b70514615@github.com>
Message-ID: <RIK2pRrJLRPJeUiPX0CrE5bdE_Dryy1UevL7-uNpP1Y=.32375568-449f-4fb5-a5fc-a8b71458257e@github.com>

On Tue, 3 May 2022 18:35:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I think 3 processes required for this testing.
>> 1. Start test process on ja_JP.eucjp locale
>> 2. Set the test data by encoder
>> 3. Verify the encoded data by decoder
>> 
>> To verify the encoded data, I think I need to check the byte data.
>
> Do we need to verify the intermediate byte encoding? Could we simply compare the text given to environ.put() in Start process and System.getenv() in Verify process match?

Hello @naotoj .
I think if 2nd process' encoder (like UTF-8) and 3rd process' decoder are same encoding, System.getenv() returns expected data.
Actually the testcase checks 3 parts on Verify process:
1. Expected environment variable is defined or not (it uses System.getenv())
2. Expected argument is received or not
3. Expected environment variable is encoded by proper encoding

When I ran this testcase with jdk18.0.1, I got following result:

Unexpected argument was received: \u6F22\u5B57<->\u7FB2\u221A\uFFFD
Unexpected environment variables: \xE6\xBC\xA2\xE5\xAD\x97\x3D\xE6\xBC\xA2\xE5\xAD\x97

It means 1st test was passed, 2nd and 3rd test were failed.
I don't think environment variable issue can be seen without 3rd test.
Please let me know if you find out another way.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From smarks at openjdk.java.net  Wed May  4 03:14:18 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 4 May 2022 03:14:18 GMT
Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v21]
In-Reply-To: <4w0QnRsUSRuWQ1idjWGJbaj4GlE0MNBLblzCNIv46oA=.9237162f-3aaf-461a-9d5f-d5e5131a332e@github.com>
References: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
 <4w0QnRsUSRuWQ1idjWGJbaj4GlE0MNBLblzCNIv46oA=.9237162f-3aaf-461a-9d5f-d5e5131a332e@github.com>
Message-ID: <gz54VbVv0d5ZVptBomEOJqhh3yJy5IwYzbw_KA_O_-w=.0009f699-cc78-4f00-8500-22d9369e02c9@github.com>

On Sun, 1 May 2022 17:48:39 GMT, Yasser Bazzi <duke at openjdk.java.net> wrote:

>> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface.
>> 
>> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it.
>> 
>> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4
>
> Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update specs of setSeed() and next(bits).

OK, thanks for merging. I've updated the CSR and have re-proposed it, and I'm rerunning all the tests.

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

PR: https://git.openjdk.java.net/jdk/pull/7001

From darcy at openjdk.java.net  Wed May  4 04:02:33 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 4 May 2022 04:02:33 GMT
Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v21]
In-Reply-To: <4w0QnRsUSRuWQ1idjWGJbaj4GlE0MNBLblzCNIv46oA=.9237162f-3aaf-461a-9d5f-d5e5131a332e@github.com>
References: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
 <4w0QnRsUSRuWQ1idjWGJbaj4GlE0MNBLblzCNIv46oA=.9237162f-3aaf-461a-9d5f-d5e5131a332e@github.com>
Message-ID: <pgFXadak-bu-wpYAxcL64meUpb1H-w15tAsYJZDPQQc=.1dc2a751-36ec-441c-bce5-113547d1b7fd@github.com>

On Sun, 1 May 2022 17:48:39 GMT, Yasser Bazzi <duke at openjdk.java.net> wrote:

>> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface.
>> 
>> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it.
>> 
>> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4
>
> Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update specs of setSeed() and next(bits).

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7001

From almatvee at openjdk.java.net  Wed May  4 04:02:59 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 4 May 2022 04:02:59 GMT
Subject: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as
 "damaged"
Message-ID: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>

- No changes to code provided by original fix.
 - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute unsigned code and code should be at least ad hoc signed.
 - Signing of app bundle produced by AppContentTest.java fails, since it has invalid app bundle structure with added files into Content folder. Thus test is executed but failure is always expected on macOS aarch64.

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

Commit messages:
 - 8277493: [REDO] Quarantined jpackage apps are labeled as "damaged"

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

PR: https://git.openjdk.java.net/jdk/pull/8527

From smarks at openjdk.java.net  Wed May  4 05:06:38 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 4 May 2022 05:06:38 GMT
Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v21]
In-Reply-To: <4w0QnRsUSRuWQ1idjWGJbaj4GlE0MNBLblzCNIv46oA=.9237162f-3aaf-461a-9d5f-d5e5131a332e@github.com>
References: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
 <4w0QnRsUSRuWQ1idjWGJbaj4GlE0MNBLblzCNIv46oA=.9237162f-3aaf-461a-9d5f-d5e5131a332e@github.com>
Message-ID: <jO-xDxx5SoBeQshd_t8w9k19Rq7S4vk3sT_eVR-0Ao4=.11355870-064a-42c4-9830-b4b1fa08650a@github.com>

On Sun, 1 May 2022 17:48:39 GMT, Yasser Bazzi <duke at openjdk.java.net> wrote:

>> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface.
>> 
>> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it.
>> 
>> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4
>
> Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update specs of setSeed() and next(bits).

Marked as reviewed by smarks (Reviewer).

OK to integrate. I will sponsor.

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

PR: https://git.openjdk.java.net/jdk/pull/7001

From ssahoo at openjdk.java.net  Wed May  4 07:00:25 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Wed, 4 May 2022 07:00:25 GMT
Subject: Integrated: 8285452: Add a new test library API to replace a file
 content using FileUtils.java
In-Reply-To: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
References: <VN1XtPt4EZTjMhWoZaytuvM9fgAG5o7NCAmvzdR6CSw=.daabe672-b7e7-4924-bf73-5acc0b25448a@github.com>
Message-ID: <BtFZmQPRfsi19yCupNRE1uVkqy5fcBecSXFH2Vygy-8=.e4c1e560-029d-4de3-b432-5336fa0746f8@github.com>

On Fri, 22 Apr 2022 12:16:07 GMT, Sibabrata Sahoo <ssahoo at openjdk.org> wrote:

> A new API to support replacing selective lines with desired content.

This pull request has now been integrated.

Changeset: 0462d5a2
Author:    Sibabrata Sahoo <ssahoo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0462d5a25258458ec7f40d76b9d910ee529f3647
Stats:     163 lines in 2 files changed: 162 ins; 0 del; 1 mod

8285452: Add a new test library API to replace a file content using FileUtils.java

Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: weijun, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/8360

From mbaesken at openjdk.java.net  Wed May  4 07:37:14 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 4 May 2022 07:37:14 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]
In-Reply-To: <O91M8nZ3f4LIL_JqrgtCqQ-oDAb7IKptzdRZvoAhI3Y=.8748256a-aaec-47f7-8ba2-79befaedff4a@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <O91M8nZ3f4LIL_JqrgtCqQ-oDAb7IKptzdRZvoAhI3Y=.8748256a-aaec-47f7-8ba2-79befaedff4a@github.com>
Message-ID: <kgOMZxoxZ2AX5v-gcnxMD_FXRdgLztANEWShfG5l5Mw=.fcff8e59-76b1-4051-ade8-2d1a1fca3478@github.com>

On Tue, 3 May 2022 07:10:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust Copyright year in wepoll.c

Interesting fact :
we run now into this compile error :

d:\a\jdk\jdk\jdk\src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp(1262): error C2065: 'NCRYPT_CIPHER_KEY_BLOB': undeclared identifier
d:\a\jdk\jdk\jdk\src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp(1280): error C2065: 'NCRYPT_PROTECTED_KEY_BLOB': undeclared identifier

Reason seems that already for some time  ( at least OpenJDK 11 (!) )  we have an implicit minimum requirement of Windows 8 / Windows 2012
APIs for this code, so enforcing Win 7 is too old :

https://docs.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptexportkey

NCRYPT_PROTECTED_KEY_BLOB
Export a protected key in a NCRYPT_KEY_BLOB_HEADER structure.

Windows 8 and Windows Server 2012:  Support for this value begins.

NCRYPT_CIPHER_KEY_BLOB
Export a cipher key in a NCRYPT_KEY_BLOB_HEADER structure.

Windows 8 and Windows Server 2012:  Support for this value begins.

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From mbaesken at openjdk.java.net  Wed May  4 07:42:14 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 4 May 2022 07:42:14 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v3]
In-Reply-To: <PIDh6k2k57rpJwLeWy2gBFLx3eYmMlRtzXj7ImR3qPM=.e58bf209-91c1-46ea-a661-a5a6bb7195ba@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <O91M8nZ3f4LIL_JqrgtCqQ-oDAb7IKptzdRZvoAhI3Y=.8748256a-aaec-47f7-8ba2-79befaedff4a@github.com>
 <PIDh6k2k57rpJwLeWy2gBFLx3eYmMlRtzXj7ImR3qPM=.e58bf209-91c1-46ea-a661-a5a6bb7195ba@github.com>
Message-ID: <9KE3CEXRqW4z5bQgy9E5ydrFvcxY4LgV9zA-KGRH09M=.e21bbecb-5e37-4887-9a74-7e4227c70c07@github.com>

On Tue, 3 May 2022 13:27:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I agree with Erik - the source locations need to be modified to not define it. If we want to keep a record perhaps add an assertion that the value is what was expected?
> 
> I still feel we have a disconnect between this and an actual check for what the build and runtime platform version is ...
> 
> and it isn't at all clear how someone using an API only in a later Windows version, and so setting _WIN32_WINNT to a higher value, will know that this is defined down in the build files ?

Hi David, I agree the other locations as long as they are not 3rd party code should be cleaned up.
Someone using an API  that is only available in later Windows versions would get  a redefinition warning as long as no undefine is done.
But we have to set _WIN32_WINNT anyway to a higher value (windows8, I think that's 0x0602)  to  compile 
 src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp .

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From mbaesken at openjdk.java.net  Wed May  4 08:00:08 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 4 May 2022 08:00:08 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

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

  adjust API level to Windows 8 for security.cpp and do some cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8428/files
  - new: https://git.openjdk.java.net/jdk/pull/8428/files/23b63c5b..721528c4

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

  Stats: 31 lines in 7 files changed: 1 ins; 26 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8428.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8428/head:pull/8428

PR: https://git.openjdk.java.net/jdk/pull/8428

From dholmes at openjdk.java.net  Wed May  4 08:38:24 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 4 May 2022 08:38:24 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
Message-ID: <iMA0pSqzQRdteblNyOe8cqE968h9tbYi23Unx5RkCSA=.3ac8f2a3-c445-42f2-8431-fc942616f3b9@github.com>

On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust API level to Windows 8 for security.cpp and do some cleanup

I'm confused.  `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set _WIN32_WINNT so how is that later API being enabled? Does this mean that not setting _WIN32_WINNT means :any API is allowed" ?

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From mbaesken at openjdk.java.net  Wed May  4 09:11:17 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 4 May 2022 09:11:17 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <iMA0pSqzQRdteblNyOe8cqE968h9tbYi23Unx5RkCSA=.3ac8f2a3-c445-42f2-8431-fc942616f3b9@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
 <iMA0pSqzQRdteblNyOe8cqE968h9tbYi23Unx5RkCSA=.3ac8f2a3-c445-42f2-8431-fc942616f3b9@github.com>
Message-ID: <HxGEWDrc8r3LwkIXozfaxZf-b9aNcL_v-U39YTua1dY=.d0287a56-ddac-48a0-b4e7-06ab6a81e454@github.com>

On Wed, 4 May 2022 08:34:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm confused. `src\jdk.crypto.mscapi\windows\native\libsunmscapi\security.cpp` doesn't set _WIN32_WINNT so how is that later API being enabled? Does this mean that not setting _WIN32_WINNT means :any API is allowed" ?

I found this info  here  https://stackoverflow.com/questions/37668692/visual-studio-setting-winver-win32-winnt-to-windows-8-on-windows-7
"VS 2012 uses the Windows 8.0 SDK which defaults to _WIN32_WINNT=0x0602 (Windows 8). VS 2013 / 2015 uses the Windows 8.1 SDK which defaults to _WIN32_WINNT=0x0603 (Windows 8.1). If you use VS 2015 and the Windows 10 SDK, it defaults to _WIN32_WINNT=0x0A00 (Windows 10)."

So it seems you get some more or less recent default when working with a not too old compiler/SDK.

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From sgehwolf at openjdk.java.net  Wed May  4 09:22:11 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 4 May 2022 09:22:11 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v15]
In-Reply-To: <QBPcPVkHSe9Q0n8rRgamgLg3XJ8trPcC3X5TK2YlpbU=.0ded1300-8d9e-4318-8b58-a9e60ea6dbc6@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <QBPcPVkHSe9Q0n8rRgamgLg3XJ8trPcC3X5TK2YlpbU=.0ded1300-8d9e-4318-8b58-a9e60ea6dbc6@github.com>
Message-ID: <EYvm5wQVnVp1mXKu7RA1N6odbAvr0_N23drbbuD3Xgw=.1c13e397-68a8-4f15-b683-dfaf80916452@github.com>

On Wed, 4 May 2022 01:37:27 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update code

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 154:

> 152:       log_trace(os, container)("Memory and Swap Limit has been reset to " JULONG_FORMAT " because swappiness is 0", memlimit);
> 153:       return memlimit;
> 154:     }

It now occurs to me that we'd need the same treatment of this on line `143`. Perhaps extract a function and call it in both places?

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

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Wed May  4 09:46:00 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 4 May 2022 09:46:00 GMT
Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to
 reduce allocation pressure [v2]
In-Reply-To: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
References: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
Message-ID: <mWNCEl3SGAnUluIIw9IZVtzwFcQAuOfJlzylwZ3s2tE=.58bc7b09-ecd3-491a-8a85-9195ba52ae32@github.com>

> `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from.

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

  8282701: Revert some irrelevant changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7714/files
  - new: https://git.openjdk.java.net/jdk/pull/7714/files/f13239c3..b79f1ddb

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

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

PR: https://git.openjdk.java.net/jdk/pull/7714

From duke at openjdk.java.net  Wed May  4 09:48:49 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 4 May 2022 09:48:49 GMT
Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to
 reduce allocation pressure [v2]
In-Reply-To: <mWNCEl3SGAnUluIIw9IZVtzwFcQAuOfJlzylwZ3s2tE=.58bc7b09-ecd3-491a-8a85-9195ba52ae32@github.com>
References: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
 <mWNCEl3SGAnUluIIw9IZVtzwFcQAuOfJlzylwZ3s2tE=.58bc7b09-ecd3-491a-8a85-9195ba52ae32@github.com>
Message-ID: <Pv9z1qERovJoQnGMEzruTK_dV7c_JTflblHBYRotaFk=.ff836c56-76ea-4e7e-b0d5-02447210a272@github.com>

On Wed, 4 May 2022 09:46:00 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282701: Revert some irrelevant changes

I've reverted changes to `getInterface(boolean)`

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

PR: https://git.openjdk.java.net/jdk/pull/7714

From mcimadamore at openjdk.java.net  Wed May  4 10:58:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 10:58:31 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>

On Tue, 3 May 2022 12:07:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

Changes look generally good. Personally, I found the changes in Flow the harder to follow - but I that part is just hard (even in the spec), as it has to perform a search in both breadth (as records have more than one component) and in depth (as patterns can be nested). I've added some comments to check my understanding.

src/java.base/share/classes/java/lang/MatchException.java line 41:

> 39:  *        constants at runtime than it had at compilation time, or the type hierarchy has changed
> 40:  *        in incompatible ways between compile time and run time.</li>
> 41:  *    <li>Null targets and sealed types. If an interface or abstract class {@code C} is sealed

Should this be `null targets and nested sealed type test patterns` ?

Also, not sure `null` target is the right expression - maybe `null and nested xyz` would work better?

src/jdk.compiler/share/classes/com/sun/source/tree/DeconstructionPatternTree.java line 43:

> 41:      * @return the deconstructed type
> 42:      */
> 43:     Tree getDeconstructor();

Shouldn't this return an ExpressionTree?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4180:

> 4178:             type = attribTree(tree.var.vartype, env, varInfo);
> 4179:         } else {
> 4180:             type = resultInfo.pt;

Looks good - infers the binging var type from the record component being processed. If not in a record, then I suspect resultInfo.pt is just the target expression type (e.g. var in toplevel environment).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 750:

> 748:         private Set<Symbol> coveredSymbols(DiagnosticPosition pos, Type targetType,
> 749:                                            Iterable<? extends JCCaseLabel> labels) {
> 750:             Set<Symbol> constants = new HashSet<>();

Should this be called `constants` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 824:

> 822:                 }
> 823:                 for (Symbol currentType : nestedCovered) {
> 824:                     if (types.isSubtype(types.erasure(currentType.type),

Not 100% what this test does

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 836:

> 834:             for (Entry<Symbol, List<JCDeconstructionPattern>> e : componentType2Patterns.entrySet()) {
> 835:                 if (coversDeconstructionStartingFromComponent(pos, targetType, e.getValue(), component + 1)) {
> 836:                     covered.add(e.getKey());

So... it seems to me that what this code is doing is that, for a component index _i_, we get all its recursively covered symbols - then we add them to the set of covered symbols of component _i_, but only if components _w_, where _w_ > _i_ are also covered? That is, if in `R(P1, P2, ... Pn)`, we see that `P1` is covered, but `P2` is not, we also consider `P1` not covered (which in turn makes `R` not covered).

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 788:

> 786:             }
> 787:             if (token.kind == LPAREN) {
> 788:                 ListBuffer<JCPattern> nested = new ListBuffer<>();

should we add comment saying "deconstruction pattern"

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 808:

> 806:                 pattern = toP(F.at(pos).DeconstructionPattern(e, nested.toList(), var));
> 807:             } else {
> 808:                 JCVariableDecl var = toP(F.at(token.pos).VarDef(mods, ident(), e, null));

and, here, a comment saying "type test pattern" ?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1004:

> 1002:                     JCExpression type = unannotatedType(false);
> 1003:                     if (token.kind == IDENTIFIER) {
> 1004:                         checkSourceLevel(token.pos, Feature.PATTERN_MATCHING_IN_INSTANCEOF);

Two question/comments:
* I believe that `checkSourceLevel` is called here, but not in `analyzePattern` because `analyzePattern` is also called in the `switch` code, in which case we already check for source level which supports pattern in switch, correct?
* For type test pattern, this code recurses to parsePattern, which seems correct, but the same doesn't happen for deconstructor patterns. Apart from the initial "peek" the code seems otherwise the same - would it be possible to consolidate?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3186:

> 3184:                                 : PatternResult.PATTERN;
> 3185:                     }
> 3186:                     parentDepth++; break;

* s/parentDepth/parenDepth
* maybe s/depth/typeDepth

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mcimadamore at openjdk.java.net  Wed May  4 10:58:33 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 10:58:33 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
Message-ID: <aXWInt5Fx8rtPdhD0B4IGHpEeXf8azyT99uPFsmZUpA=.1d0e2315-7c53-4d63-8f07-cb1460513d67@github.com>

On Wed, 4 May 2022 09:59:33 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4180:
> 
>> 4178:             type = attribTree(tree.var.vartype, env, varInfo);
>> 4179:         } else {
>> 4180:             type = resultInfo.pt;
> 
> Looks good - infers the binging var type from the record component being processed. If not in a record, then I suspect resultInfo.pt is just the target expression type (e.g. var in toplevel environment).

That said, I'm not sure how this connects with `instanceof`. This patch doesn't seem to alter `visitTypeTest`. In the current code I can see this:

if (tree.pattern.getTag() == BINDINGPATTERN ||
           tree.pattern.getTag() == PARENTHESIZEDPATTERN) {
           attribTree(tree.pattern, env, unknownExprInfo);
           ...
           

This seems wrong for two reasons:

* it doesn't take into account the new pattern tag
* it uses an "unknown" result info when attributing, meaning that any toplevel `var` pattern will not be attributed correctly

But we seem to have tests covering record patterns and instanceof. so I'm wondering if I'm missing some code update?

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mbaesken at openjdk.java.net  Wed May  4 11:44:47 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 4 May 2022 11:44:47 GMT
Subject: RFR: JDK-8286114: [test] show real exception in bomb call in
 sun/rmi/runtime/Log/checkLogging/CheckLogging.java
Message-ID: <sHVrQ04L1B9oiC0m5LDLjRr6pPxpdM3tvWqdwfQCIY4=.56e0314c-4e94-48bf-a0f2-5b6283f232d3@github.com>

There is one TestLibrary.bomb call in sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the exception to bomb, that should be improved.

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

Commit messages:
 - JDK-8286114

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

PR: https://git.openjdk.java.net/jdk/pull/8533

From mbaesken at openjdk.java.net  Wed May  4 12:10:39 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 4 May 2022 12:10:39 GMT
Subject: RFR: JDK-8285987: executing shell scripts without #! fails on Alpine
 linux
Message-ID: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>

A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 .
Looks like this is a known issue on musl / Alpine, see also
https://www.openwall.com/lists/musl/2018/03/09/2
and
https://github.com/scala-steward-org/scala-steward/issues/1374
(we see it on Alpine 3.15).

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

Commit messages:
 - JDK-8285987

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

PR: https://git.openjdk.java.net/jdk/pull/8535

From alanb at openjdk.java.net  Wed May  4 12:12:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 4 May 2022 12:12:48 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

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

 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
 - Merge with jdk-19+19
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=10
  Stats: 102779 lines in 1140 files changed: 92909 ins; 4219 del; 5651 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From dl at openjdk.java.net  Wed May  4 12:24:23 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Wed, 4 May 2022 12:24:23 GMT
Subject: RFR: 8277090 :  jsr166 refresh for jdk19 [v3]
In-Reply-To: <JvRq6Fr1LSAgXBOjVfD1J_zm4vdmuib0YCobgi58iak=.01f0eb57-5beb-4a43-a9b7-ec666f6725bb@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
 <JvRq6Fr1LSAgXBOjVfD1J_zm4vdmuib0YCobgi58iak=.01f0eb57-5beb-4a43-a9b7-ec666f6725bb@github.com>
Message-ID: <gN6c2AWqCSyZFVGYpypHE3pJ1eeQNcWttiay_CRzDQ8=.6a914b34-8da2-4c4a-8188-2a29edc2ab09@github.com>

On Tue, 3 May 2022 23:10:44 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix internal doc typos; thanks to Martin for finding these.

Out of caution about the extraneous commits in this PR, I will close this, and replace with a v2 momentarily.

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From dl at openjdk.java.net  Wed May  4 12:29:35 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Wed, 4 May 2022 12:29:35 GMT
Subject: Withdrawn: 8277090 :  jsr166 refresh for jdk19
In-Reply-To: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
References: <qj11ZOOuQzJrinzKxnb6IrGaaJOqc1SgkZN6W8rdtnI=.60049fb8-80c2-450f-a547-d52fdec60b4e@github.com>
Message-ID: <DhDgKxIzjIvDRJd4DVRzSSDAq9UQW1Zou3Jft03Mw38=.ec7323f3-e746-43ff-91c8-898a801eb57b@github.com>

On Sun, 1 May 2022 10:53:55 GMT, Doug Lea <dl at openjdk.org> wrote:

> This is the jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8490

From dl at openjdk.java.net  Wed May  4 12:38:51 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Wed, 4 May 2022 12:38:51 GMT
Subject: RFR: 8277090 : jsr166 refresh for jdk19 v2
Message-ID: <UUobv0Q3oBCj_jndOcqmmWCxUgspsMNICaT5o6MUZ7M=.45371a8c-d9c2-436f-88a4-19fa4df4858b@github.com>

This is the revised jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090. Out of caution, this PR removes the unrelated commits from original version.

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

Commit messages:
 - Redoing JDK-8277090 to avoid stray commits

Changes: https://git.openjdk.java.net/jdk/pull/8536/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8536&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277090
  Stats: 3367 lines in 13 files changed: 1731 ins; 645 del; 991 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8536.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8536/head:pull/8536

PR: https://git.openjdk.java.net/jdk/pull/8536

From rriggs at openjdk.java.net  Wed May  4 13:48:24 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 4 May 2022 13:48:24 GMT
Subject: RFR: JDK-8286114: [test] show real exception in bomb call in
 sun/rmi/runtime/Log/checkLogging/CheckLogging.java
In-Reply-To: <sHVrQ04L1B9oiC0m5LDLjRr6pPxpdM3tvWqdwfQCIY4=.56e0314c-4e94-48bf-a0f2-5b6283f232d3@github.com>
References: <sHVrQ04L1B9oiC0m5LDLjRr6pPxpdM3tvWqdwfQCIY4=.56e0314c-4e94-48bf-a0f2-5b6283f232d3@github.com>
Message-ID: <sQA-P6D-iRClN0WGBtvXa43QZWJHnxJx-sqquc_5LAo=.bbd9371d-84f1-49da-a6cb-7fa9035d1842@github.com>

On Wed, 4 May 2022 11:37:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is one TestLibrary.bomb call in sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the exception to bomb, that should be improved.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8533

From mdoerr at openjdk.java.net  Wed May  4 14:13:23 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 4 May 2022 14:13:23 GMT
Subject: RFR: JDK-8286114: [test] show real exception in bomb call in
 sun/rmi/runtime/Log/checkLogging/CheckLogging.java
In-Reply-To: <sHVrQ04L1B9oiC0m5LDLjRr6pPxpdM3tvWqdwfQCIY4=.56e0314c-4e94-48bf-a0f2-5b6283f232d3@github.com>
References: <sHVrQ04L1B9oiC0m5LDLjRr6pPxpdM3tvWqdwfQCIY4=.56e0314c-4e94-48bf-a0f2-5b6283f232d3@github.com>
Message-ID: <q-rt5kaGNA0gsTY2YuroFb5gEW2g_mMgcO14bNtmgHs=.78f3a6ba-739c-4171-8cd6-ca748f356b15@github.com>

On Wed, 4 May 2022 11:37:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is one TestLibrary.bomb call in sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the exception to bomb, that should be improved.

Marked as reviewed by mdoerr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8533

From mbaesken at openjdk.java.net  Wed May  4 14:19:22 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 4 May 2022 14:19:22 GMT
Subject: RFR: JDK-8286114: [test] show real exception in bomb call in
 sun/rmi/runtime/Log/checkLogging/CheckLogging.java
In-Reply-To: <sHVrQ04L1B9oiC0m5LDLjRr6pPxpdM3tvWqdwfQCIY4=.56e0314c-4e94-48bf-a0f2-5b6283f232d3@github.com>
References: <sHVrQ04L1B9oiC0m5LDLjRr6pPxpdM3tvWqdwfQCIY4=.56e0314c-4e94-48bf-a0f2-5b6283f232d3@github.com>
Message-ID: <8UfWAg5l-OcG-t5NUNRZAgDkI-KLv3TC18my0_G-oOM=.f2057103-6967-4af4-99a6-2172ff56260c@github.com>

On Wed, 4 May 2022 11:37:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is one TestLibrary.bomb call in sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the exception to bomb, that should be improved.

Hi Roger and Martin, thanks for the reviews !

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

PR: https://git.openjdk.java.net/jdk/pull/8533

From alanb at openjdk.java.net  Wed May  4 14:28:24 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 4 May 2022 14:28:24 GMT
Subject: RFR: 8277090 : jsr166 refresh for jdk19
In-Reply-To: <UUobv0Q3oBCj_jndOcqmmWCxUgspsMNICaT5o6MUZ7M=.45371a8c-d9c2-436f-88a4-19fa4df4858b@github.com>
References: <UUobv0Q3oBCj_jndOcqmmWCxUgspsMNICaT5o6MUZ7M=.45371a8c-d9c2-436f-88a4-19fa4df4858b@github.com>
Message-ID: <GhzLd9sDKDRa-fWQK9RzqTfpy0dk1blQUy17oVAJ5w8=.a340771e-9f82-4fe3-95ef-c0309ad6e951@github.com>

On Wed, 4 May 2022 12:30:53 GMT, Doug Lea <dl at openjdk.org> wrote:

> This is the revised jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090. Out of caution, this PR removes the unrelated commits from original version.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8536

From mbaesken at openjdk.java.net  Wed May  4 14:35:27 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 4 May 2022 14:35:27 GMT
Subject: Integrated: JDK-8286114: [test] show real exception in bomb call in
 sun/rmi/runtime/Log/checkLogging/CheckLogging.java
In-Reply-To: <sHVrQ04L1B9oiC0m5LDLjRr6pPxpdM3tvWqdwfQCIY4=.56e0314c-4e94-48bf-a0f2-5b6283f232d3@github.com>
References: <sHVrQ04L1B9oiC0m5LDLjRr6pPxpdM3tvWqdwfQCIY4=.56e0314c-4e94-48bf-a0f2-5b6283f232d3@github.com>
Message-ID: <PvGgd647y-WOIo6iqw-yHYVSVjtWBUtF_okIIA27Ao8=.ac92480c-137d-48cc-90ce-f83d6488ba38@github.com>

On Wed, 4 May 2022 11:37:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is one TestLibrary.bomb call in sun/rmi/runtime/Log/checkLogging/CheckLogging.java that is not passing the exception to bomb, that should be improved.

This pull request has now been integrated.

Changeset: 7424f475
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7424f47557be54c781f64f1c0c9265e11fe40acf
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8286114: [test] show real exception in bomb call in sun/rmi/runtime/Log/checkLogging/CheckLogging.java

Reviewed-by: rriggs, mdoerr

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

PR: https://git.openjdk.java.net/jdk/pull/8533

From jpai at openjdk.java.net  Wed May  4 15:06:20 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 4 May 2022 15:06:20 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v2]
In-Reply-To: <4XJX8EqCKg6NfIgEIyodh-cSuAIiCE2U3udBELzfHfU=.954deb03-ba07-4904-a1fd-9ee6173bc157@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <4XJX8EqCKg6NfIgEIyodh-cSuAIiCE2U3udBELzfHfU=.954deb03-ba07-4904-a1fd-9ee6173bc157@github.com>
Message-ID: <xtdHeFzawIikwPXvBzWQzNTskLV0D1N8cM5eSUjYLkU=.95105955-b28c-46e7-a63d-e421a9e2f48e@github.com>

On Fri, 29 Apr 2022 03:00:40 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Assertions over return values. Some refinement of equals() testing.
>  - Add comment about Map.Entry identity not guaranteed.

Hello Stuart, I had a look at the updates. This looks good to me, thank you for the changes. Just a couple of comments/questions that I've included at relevant lines.

test/jdk/java/util/IdentityHashMap/Basic.java line 50:

> 48: // that a map's entrySet contains exactly the expected mappings. In most cases, keys and
> 49: // values should be compared by identity, not equality. However, the identities of Map.Entry
> 50: // instances from an IdentityHashSet are not guaranteed; the keys and values they contain

I think I understand what you are saying here, but it took me a few reads to understand it. More so because of `IdentityHashSet` here, which I think is a typo.
So what's being stated here is that you cannot do something like:

IdentityHashMap m = new IdentityHashMap();
...
var e1 = m.entrySet();
var e2 = m.entrySet();

assertSame(e1, e2); // this isn't guaranteed to pass

Did I understand this right?

test/jdk/java/util/IdentityHashMap/Basic.java line 500:

> 498:         Box newKey = new Box(k1a);
> 499:         Box newVal = new Box(v1a);
> 500:         Box r = map.computeIfAbsent(newKey, k -> { called[0] = true; return newVal; });

More of a curiosity than a review comment - I see that various places in this PR use a boolean array with one element instead of just a boolean type. Is that a personal coding preference or is there something more to it?

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From duke at openjdk.java.net  Wed May  4 15:06:20 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 4 May 2022 15:06:20 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v2]
In-Reply-To: <xtdHeFzawIikwPXvBzWQzNTskLV0D1N8cM5eSUjYLkU=.95105955-b28c-46e7-a63d-e421a9e2f48e@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <4XJX8EqCKg6NfIgEIyodh-cSuAIiCE2U3udBELzfHfU=.954deb03-ba07-4904-a1fd-9ee6173bc157@github.com>
 <xtdHeFzawIikwPXvBzWQzNTskLV0D1N8cM5eSUjYLkU=.95105955-b28c-46e7-a63d-e421a9e2f48e@github.com>
Message-ID: <GNcNLDkJvhllvmuXeCG0efKRiYaa5YH-xJprqgtzNDA=.5a1a59e1-a822-4a87-a35e-75a5a9c6cfae@github.com>

On Wed, 4 May 2022 14:57:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Assertions over return values. Some refinement of equals() testing.
>>  - Add comment about Map.Entry identity not guaranteed.
>
> test/jdk/java/util/IdentityHashMap/Basic.java line 500:
> 
>> 498:         Box newKey = new Box(k1a);
>> 499:         Box newVal = new Box(v1a);
>> 500:         Box r = map.computeIfAbsent(newKey, k -> { called[0] = true; return newVal; });
> 
> More of a curiosity than a review comment - I see that various places in this PR use a boolean array with one element instead of just a boolean type. Is that a personal coding preference or is there something more to it?

This just serves as a modifiable boolean like an AtomicBoolean. Remember lambdas can only use final local var references (due to how they work), and it cannot access or modify the local variable in the caller method.

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From duke at openjdk.java.net  Wed May  4 15:04:40 2022
From: duke at openjdk.java.net (Yasser Bazzi)
Date: Wed, 4 May 2022 15:04:40 GMT
Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v22]
In-Reply-To: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
References: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
Message-ID: <4KWuFLj5UXPb9y7n-xkIoPB6Ogb7Cs7N3YYwna78yE4=.a17e7d1b-c2c3-4f36-a3b9-0959b5b11a22@github.com>

> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface.
> 
> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it.
> 
> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4

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

  Update full name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7001/files
  - new: https://git.openjdk.java.net/jdk/pull/7001/files/a28ba8e9..bc5516c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=20-21

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

PR: https://git.openjdk.java.net/jdk/pull/7001

From shade at openjdk.java.net  Wed May  4 16:05:06 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 4 May 2022 16:05:06 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
Message-ID: <Q3DstnYGNVgBXkn57bQirgdwlubtfPhnhkirhbjZMjk=.ad2e9a0f-b49c-47ad-b7c3-88037905f3ad@github.com>

On Wed, 4 May 2022 12:12:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75

> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.

So, does this PR pass current GHA checks? I see they are not enabled for this PR. It would be unfortunate for this large integration to break builds/tests for smaller PRs that would follow it.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Wed May  4 16:56:40 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 4 May 2022 16:56:40 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
Message-ID: <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>

On Tue, 3 May 2022 10:40:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:
> 
>  - Merge branch 'master' into foreign-preview
>  - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Tweak support for Linker lookup
>    Improve javadoc of SymbolLookup
>  - Tweak Addressable javadoc
>  - Downcall and upcall tests use wrong layout which is missing some trailing padding
>  - Simplify libraryLookup impl
>  - Address CSR comments
>  - Merge branch 'master' into foreign-preview
>  - Add ValueLayout changes
>  - Tweak support for array element var handle
>  - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 116:

> 114:  * Linker nativeLinker = Linker.nativeLinker();
> 115:  * SymbolLookup stdlib = nativeLinker.defaultLookup();
> 116:  * MemorySegment malloc = stdlib.lookup("malloc");

This?should?be:
Suggestion:

 * Optional<MemorySegment> malloc = stdlib.lookup("malloc");

or
Suggestion:

 * MemorySegment malloc = stdlib.lookup("malloc").orElseThrow();

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153:

> 151:     static SymbolLookup loaderLookup() {
> 152:         Class<?> caller = Reflection.getCallerClass();
> 153:         ClassLoader loader = Objects.requireNonNull(caller.getClassLoader());

Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]?

[^1]: This?happens when?`caller` is?on the?bootstrap?classpath.
[^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack.

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From psandoz at openjdk.java.net  Wed May  4 16:57:33 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 4 May 2022 16:57:33 GMT
Subject: RFR: 8277090 : jsr166 refresh for jdk19
In-Reply-To: <UUobv0Q3oBCj_jndOcqmmWCxUgspsMNICaT5o6MUZ7M=.45371a8c-d9c2-436f-88a4-19fa4df4858b@github.com>
References: <UUobv0Q3oBCj_jndOcqmmWCxUgspsMNICaT5o6MUZ7M=.45371a8c-d9c2-436f-88a4-19fa4df4858b@github.com>
Message-ID: <mhmYhZN6JzYaRDeaIILuBTc9GBm6MbAhXG_-kSjjk-A=.1116e814-0ec7-4cc8-ac63-62b92e1dcc34@github.com>

On Wed, 4 May 2022 12:30:53 GMT, Doug Lea <dl at openjdk.org> wrote:

> This is the revised jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090. Out of caution, this PR removes the unrelated commits from original version.

Marked as reviewed by psandoz (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8536

From itakiguchi at openjdk.java.net  Wed May  4 17:09:32 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 4 May 2022 17:09:32 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v4]
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <1dZ6o94-xt1oOEevAAO3uYDQrjStchH0FfrHi88V1OE=.bbc63a8f-7959-46fa-ad9c-292c09e80ae5@github.com>

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

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

  8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8378/files
  - new: https://git.openjdk.java.net/jdk/pull/8378/files/9db79874..84e6d639

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

  Stats: 107 lines in 2 files changed: 40 ins; 60 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8378/head:pull/8378

PR: https://git.openjdk.java.net/jdk/pull/8378

From itakiguchi at openjdk.java.net  Wed May  4 17:10:42 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 4 May 2022 17:10:42 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v4]
In-Reply-To: <0oFVCJWhQrze7dIhCE5j3VfKkWW-XkW40UduBmB_KiE=.2c75dc1b-415a-4e41-bb9f-5e32dfd7f470@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <0oFVCJWhQrze7dIhCE5j3VfKkWW-XkW40UduBmB_KiE=.2c75dc1b-415a-4e41-bb9f-5e32dfd7f470@github.com>
Message-ID: <RhzTcr1uOG3ouNbT-FqFOAZVAffmn5ro2Dg82GzzG-o=.a61812ce-7437-46ed-99f8-3974e1862c12@github.com>

On Tue, 26 Apr 2022 21:17:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> Thanks for fixing the issue.
> As to the test, it has lots of redundancy, and too complicated to me. Can you simplify the test?

Hello @naotoj .
I removed `i18nEnvArg.sh` and modified `i18nEnvArg.java`.
Could you review it again ?

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From simonis at openjdk.java.net  Wed May  4 17:11:22 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 4 May 2022 17:11:22 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v9]
In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
Message-ID: <3hZV2C2J0Fry73lFwZ1Kn7PIgOHxdf_d2t2VzkMABV0=.9c433fa0-e581-4ace-8a7c-98fabf64190b@github.com>

> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
> 
> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
> 
> ### TL;DR
> 
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
> 
> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
> 
> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
> 
> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*
 k*`]` (where *k* is the number of inflated bytes).
> 
> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).

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

  Updated wording based on @JoeDarcy's second CSR review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7986/files
  - new: https://git.openjdk.java.net/jdk/pull/7986/files/63ae3572..f77b3352

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=07-08

  Stats: 42 lines in 4 files changed: 0 ins; 24 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7986.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7986/head:pull/7986

PR: https://git.openjdk.java.net/jdk/pull/7986

From simonis at openjdk.java.net  Wed May  4 17:11:23 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 4 May 2022 17:11:23 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v8]
In-Reply-To: <uzeDkNKAhJdnDR3_3AX6sp1RADEx-aCkeDALkcT3j3k=.994f3a2f-ba5f-468a-89ff-a0263cdf4c62@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <uzeDkNKAhJdnDR3_3AX6sp1RADEx-aCkeDALkcT3j3k=.994f3a2f-ba5f-468a-89ff-a0263cdf4c62@github.com>
Message-ID: <pH1LGZbuIzAQ-AahmREytZkXrRD4XyN-xEviVqFybCM=.c72568df-9858-4a57-981f-4afbffb061d2@github.com>

On Mon, 2 May 2022 12:32:25 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated wording based on @JoeDarcy's CSR review

@jddarcy requested in the [CSR](https://bugs.openjdk.java.net/browse/JDK-8283758) to directly update the API spec of `InputStream`. This considerably simplifies the whole patch because the derived classes now inherit the correct specification right from their base class and don't need to be updated anymore.

Please comment right on the [CSR](https://bugs.openjdk.java.net/browse/JDK-8283758) should you have any objections or suggestions.

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

PR: https://git.openjdk.java.net/jdk/pull/7986

From duke at openjdk.java.net  Wed May  4 17:47:44 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 4 May 2022 17:47:44 GMT
Subject: RFR: 8286029: Add classpath exemption to
 globals_vectorApiSupport_***.S.inc
Message-ID: <ie0pBgdXLFBTrs_Eg5eTOxoQiSbVaiWOC3vR45kdHxs=.3b79d9d7-4216-4bff-ac47-0ab710c42416@github.com>

Adds missing classpath exception to the header of two GPLv2 files.

Requested [here](https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2022-April/013988.html).

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

Commit messages:
 - Add classpath excemption to copyright header

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

PR: https://git.openjdk.java.net/jdk/pull/8508

From sviswanathan at openjdk.java.net  Wed May  4 17:47:45 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 4 May 2022 17:47:45 GMT
Subject: RFR: 8286029: Add classpath exemption to
 globals_vectorApiSupport_***.S.inc
In-Reply-To: <ie0pBgdXLFBTrs_Eg5eTOxoQiSbVaiWOC3vR45kdHxs=.3b79d9d7-4216-4bff-ac47-0ab710c42416@github.com>
References: <ie0pBgdXLFBTrs_Eg5eTOxoQiSbVaiWOC3vR45kdHxs=.3b79d9d7-4216-4bff-ac47-0ab710c42416@github.com>
Message-ID: <c6DMitkdo6VxqrWD78s9Rbk04oLbBcr8sHLDL58QA3g=.755f2a0b-da0a-4643-9307-f817e9d00e71@github.com>

On Mon, 2 May 2022 20:05:36 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> Adds missing classpath exception to the header of two GPLv2 files.
> 
> Requested [here](https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2022-April/013988.html).

Marked as reviewed by sviswanathan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8508

From sviswanathan at openjdk.java.net  Wed May  4 17:57:28 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 4 May 2022 17:57:28 GMT
Subject: RFR: 8286029: Add classpath exemption to
 globals_vectorApiSupport_***.S.inc
In-Reply-To: <ie0pBgdXLFBTrs_Eg5eTOxoQiSbVaiWOC3vR45kdHxs=.3b79d9d7-4216-4bff-ac47-0ab710c42416@github.com>
References: <ie0pBgdXLFBTrs_Eg5eTOxoQiSbVaiWOC3vR45kdHxs=.3b79d9d7-4216-4bff-ac47-0ab710c42416@github.com>
Message-ID: <5Ag2XPAYU_TiXCrV-Nt-yb4p9tVXVo6LF7-V_fO4Vlc=.414e701b-033a-4c44-9f72-9a5d63255226@github.com>

On Mon, 2 May 2022 20:05:36 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> Adds missing classpath exception to the header of two GPLv2 files.
> 
> Requested [here](https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2022-April/013988.html).

src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc line 4:

> 2:  * Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 4:  *

Please update the copyright year to 2022.

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

PR: https://git.openjdk.java.net/jdk/pull/8508

From duke at openjdk.java.net  Wed May  4 17:58:42 2022
From: duke at openjdk.java.net (Yasser Bazzi)
Date: Wed, 4 May 2022 17:58:42 GMT
Subject: Integrated: 8279598: Provide adapter from RandomGenerator to Random
In-Reply-To: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
References: <xQM3LFLe8Tmk-k1Ie5dWEO9AL8PW6UG8jvMKwl710cE=.7579ea99-6941-4c93-9381-09cc0b9a33d1@github.com>
Message-ID: <uBOvplk8EYSafnoVyXmNSojg-Gij_IB-Ec539OP6Mn8=.30d68443-f0df-42c7-b7ce-5e24f172bb32@github.com>

On Sat, 8 Jan 2022 21:00:37 GMT, Yasser Bazzi <duke at openjdk.java.net> wrote:

> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface.
> 
> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it.
> 
> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4

This pull request has now been integrated.

Changeset: df8c2be5
Author:    Yasser Bazzi Bordonal <yassermbb at gmail.com>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/df8c2be5fedd3a066b1d7371a3e3cbb7191977b0
Stats:     250 lines in 3 files changed: 225 ins; 3 del; 22 mod

8279598: Provide adapter from RandomGenerator to Random

Reviewed-by: smarks, darcy

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

PR: https://git.openjdk.java.net/jdk/pull/7001

From duke at openjdk.java.net  Wed May  4 18:43:23 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 4 May 2022 18:43:23 GMT
Subject: RFR: 8286029: Add classpath exemption to
 globals_vectorApiSupport_***.S.inc [v2]
In-Reply-To: <ie0pBgdXLFBTrs_Eg5eTOxoQiSbVaiWOC3vR45kdHxs=.3b79d9d7-4216-4bff-ac47-0ab710c42416@github.com>
References: <ie0pBgdXLFBTrs_Eg5eTOxoQiSbVaiWOC3vR45kdHxs=.3b79d9d7-4216-4bff-ac47-0ab710c42416@github.com>
Message-ID: <8rKYddmgFWZ8BwQf1iKduUzCRkpbGIjeMZcfGbl4r_E=.9180ee8f-ddbe-402d-b69b-96633b3f880d@github.com>

> Adds missing classpath exception to the header of two GPLv2 files.
> 
> Requested [here](https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2022-April/013988.html).

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

  Update copyright header year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8508/files
  - new: https://git.openjdk.java.net/jdk/pull/8508/files/72f74f0e..cdae1312

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

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

PR: https://git.openjdk.java.net/jdk/pull/8508

From duke at openjdk.java.net  Wed May  4 18:43:24 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 4 May 2022 18:43:24 GMT
Subject: RFR: 8286029: Add classpath exemption to
 globals_vectorApiSupport_***.S.inc [v2]
In-Reply-To: <c6DMitkdo6VxqrWD78s9Rbk04oLbBcr8sHLDL58QA3g=.755f2a0b-da0a-4643-9307-f817e9d00e71@github.com>
References: <ie0pBgdXLFBTrs_Eg5eTOxoQiSbVaiWOC3vR45kdHxs=.3b79d9d7-4216-4bff-ac47-0ab710c42416@github.com>
 <c6DMitkdo6VxqrWD78s9Rbk04oLbBcr8sHLDL58QA3g=.755f2a0b-da0a-4643-9307-f817e9d00e71@github.com>
Message-ID: <EIiO0yZ9TrcDOsfmEDM0aiIehPu7hQFMeNg1B5WoRxw=.8750300c-ca03-4d02-ac38-cb134774c31d@github.com>

On Wed, 4 May 2022 17:42:05 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright header year
>
> Marked as reviewed by sviswanathan (Reviewer).

Thank you @sviswa7.

> src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc line 4:
> 
>> 2:  * Copyright (c) 1997, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> 4:  *
> 
> Please update the copyright year to 2022.

??

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

PR: https://git.openjdk.java.net/jdk/pull/8508

From smarks at openjdk.java.net  Wed May  4 18:46:20 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 4 May 2022 18:46:20 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v3]
In-Reply-To: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
Message-ID: <ihMSfPj-zDLqWnSM2GA1gHF0RZ5-wp4ulQdW_VunwXI=.f11c9894-7efa-4fa9-85e1-607f0d2faba8@github.com>

> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.

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

  Improve wording of comment.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8354/files
  - new: https://git.openjdk.java.net/jdk/pull/8354/files/d66ad0b8..bf4af51f

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

  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8354.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8354/head:pull/8354

PR: https://git.openjdk.java.net/jdk/pull/8354

From smarks at openjdk.java.net  Wed May  4 18:46:21 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 4 May 2022 18:46:21 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v2]
In-Reply-To: <GNcNLDkJvhllvmuXeCG0efKRiYaa5YH-xJprqgtzNDA=.5a1a59e1-a822-4a87-a35e-75a5a9c6cfae@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <4XJX8EqCKg6NfIgEIyodh-cSuAIiCE2U3udBELzfHfU=.954deb03-ba07-4904-a1fd-9ee6173bc157@github.com>
 <xtdHeFzawIikwPXvBzWQzNTskLV0D1N8cM5eSUjYLkU=.95105955-b28c-46e7-a63d-e421a9e2f48e@github.com>
 <GNcNLDkJvhllvmuXeCG0efKRiYaa5YH-xJprqgtzNDA=.5a1a59e1-a822-4a87-a35e-75a5a9c6cfae@github.com>
Message-ID: <5z4WtwqBSY-WvspFJsBz3WKz2FOk2mlbMkW_eRT4MxE=.5050feaa-9f1c-4bdc-8b42-91c4abb6450e@github.com>

On Wed, 4 May 2022 15:02:43 GMT, liach <duke at openjdk.java.net> wrote:

>> test/jdk/java/util/IdentityHashMap/Basic.java line 500:
>> 
>>> 498:         Box newKey = new Box(k1a);
>>> 499:         Box newVal = new Box(v1a);
>>> 500:         Box r = map.computeIfAbsent(newKey, k -> { called[0] = true; return newVal; });
>> 
>> More of a curiosity than a review comment - I see that various places in this PR use a boolean array with one element instead of just a boolean type. Is that a personal coding preference or is there something more to it?
>
> This just serves as a modifiable boolean like an AtomicBoolean. Remember lambdas can only use final local var references (due to how they work), and it cannot access or modify the local variable in the caller method.

Yes, that's it; you can't mutate a local variable captured by a lambda.

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From smarks at openjdk.java.net  Wed May  4 18:53:28 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 4 May 2022 18:53:28 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v2]
In-Reply-To: <xtdHeFzawIikwPXvBzWQzNTskLV0D1N8cM5eSUjYLkU=.95105955-b28c-46e7-a63d-e421a9e2f48e@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <4XJX8EqCKg6NfIgEIyodh-cSuAIiCE2U3udBELzfHfU=.954deb03-ba07-4904-a1fd-9ee6173bc157@github.com>
 <xtdHeFzawIikwPXvBzWQzNTskLV0D1N8cM5eSUjYLkU=.95105955-b28c-46e7-a63d-e421a9e2f48e@github.com>
Message-ID: <q7sWIckBlWL-TmoRTictB1d47w1gRqLhZHGmVKtHms0=.9c4f9d14-0834-4e15-9df9-a2563a48d8f5@github.com>

On Wed, 4 May 2022 14:55:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Assertions over return values. Some refinement of equals() testing.
>>  - Add comment about Map.Entry identity not guaranteed.
>
> test/jdk/java/util/IdentityHashMap/Basic.java line 50:
> 
>> 48: // that a map's entrySet contains exactly the expected mappings. In most cases, keys and
>> 49: // values should be compared by identity, not equality. However, the identities of Map.Entry
>> 50: // instances from an IdentityHashSet are not guaranteed; the keys and values they contain
> 
> I think I understand what you are saying here, but it took me a few reads to understand it. More so because of `IdentityHashSet` here, which I think is a typo.
> So what's being stated here is that you cannot do something like:
> 
> IdentityHashMap m = new IdentityHashMap();
> ...
> var e1 = m.entrySet();
> var e2 = m.entrySet();
> 
> assertSame(e1, e2); // this isn't guaranteed to pass
> 
> Did I understand this right?

Yeah that comment was poorly worded, and indeed I meant the IdentityHashMap's entrySet and not IdentityHashSet. I've reworded it. I was trying to make a statement about exactly what needs to be compared if you want to make assertions about two maps being "equal" in the sense of IdentityHashMap behaving correctly. Specifically, given two maps `m1` and `m2`, clearly we don't want either of

    assertSame(m1, m2);
    assertSame(m1.entrySet(), m2.entrySet());

Instead, we want the `Map.Entry` instances to "match". However, given two entries `entry1` and `entry2` that are supposed to match, we also do not want

    assertSame(entry1, entry2);

Instead, we want

    assertSame(entry1.getKey(), entry2.getKey());
    assertSame(entry1.getValue(), entry2,getValue());

The `checkEntries` method goes to some length to get this right.

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From psandoz at openjdk.java.net  Wed May  4 19:13:27 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 4 May 2022 19:13:27 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator)
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <y_i0mcFGu-ecFHIN6nAFQ4gKkSZvR1jMu9DWHCcwwwg=.03e321ea-bb85-406c-9d1d-88c013f26bc4@github.com>

On Wed, 27 Apr 2022 11:03:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1340:

> 1338:   assert_different_registers(dst, src, vtmp1, vtmp2, vtmp3, vtmp4);
> 1339:   assert_different_registers(mask, ptmp, pgtmp);
> 1340:   // Example input:   src   = 88 77 66 45 44 33 22 11

Suggestion:

  // Example input:   src   = 88 77 66 55 44 33 22 11

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

PR: https://git.openjdk.java.net/jdk/pull/8425

From smarks at openjdk.java.net  Wed May  4 19:16:14 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 4 May 2022 19:16:14 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v4]
In-Reply-To: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
Message-ID: <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>

> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.

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

  Add some assertions for entrySet.equals and keySet.equals

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8354/files
  - new: https://git.openjdk.java.net/jdk/pull/8354/files/bf4af51f..4bb25edf

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

  Stats: 32 lines in 1 file changed: 32 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8354.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8354/head:pull/8354

PR: https://git.openjdk.java.net/jdk/pull/8354

From smarks at openjdk.java.net  Wed May  4 19:17:16 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 4 May 2022 19:17:16 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v3]
In-Reply-To: <ihMSfPj-zDLqWnSM2GA1gHF0RZ5-wp4ulQdW_VunwXI=.f11c9894-7efa-4fa9-85e1-607f0d2faba8@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <ihMSfPj-zDLqWnSM2GA1gHF0RZ5-wp4ulQdW_VunwXI=.f11c9894-7efa-4fa9-85e1-607f0d2faba8@github.com>
Message-ID: <9OFrnARy6QAbniVo9vcY0gDsrPemVWaIh9J2_hefAIA=.e8436497-55e7-4a60-9499-a7f69dee03eb@github.com>

On Wed, 4 May 2022 18:46:20 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve wording of comment.

I've added a few more assertions to cover `equals` of `entrySet` and `keySet` which I think were missing some cases. (Note that `values` returns a `Collection` which has no notion of equality.) I think this is ready now.

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From dl at openjdk.java.net  Wed May  4 19:28:30 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Wed, 4 May 2022 19:28:30 GMT
Subject: Integrated: 8277090 : jsr166 refresh for jdk19
In-Reply-To: <UUobv0Q3oBCj_jndOcqmmWCxUgspsMNICaT5o6MUZ7M=.45371a8c-d9c2-436f-88a4-19fa4df4858b@github.com>
References: <UUobv0Q3oBCj_jndOcqmmWCxUgspsMNICaT5o6MUZ7M=.45371a8c-d9c2-436f-88a4-19fa4df4858b@github.com>
Message-ID: <p3CEeSyRos2q6Ikufyq0qn3V2x0-ccbYXZWy2SKh7WI=.0a360b06-76ba-4a5c-9f24-fe0d7c3fa486@github.com>

On Wed, 4 May 2022 12:30:53 GMT, Doug Lea <dl at openjdk.org> wrote:

> This is the revised jsr166 refresh for jdk19. See https://bugs.openjdk.java.net/browse/JDK-8285450 and https://bugs.openjdk.java.net/browse/JDK-8277090. Out of caution, this PR removes the unrelated commits from original version.

This pull request has now been integrated.

Changeset: 00e6c63c
Author:    Doug Lea <dl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/00e6c63cd12e3f92d0c1d007aab4f74915616ffb
Stats:     3367 lines in 13 files changed: 1731 ins; 645 del; 991 mod

8277090: jsr166 refresh for jdk19

Reviewed-by: alanb, psandoz

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

PR: https://git.openjdk.java.net/jdk/pull/8536

From kvn at openjdk.java.net  Wed May  4 19:59:18 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 4 May 2022 19:59:18 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
In-Reply-To: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
Message-ID: <KdpuTVQMeytKodsxscUf6bY-Rb9ZX1mh-JlqxGz3yhc=.ad30bd97-86fe-4ae8-80ff-277eacce88d9@github.com>

On Wed, 4 May 2022 01:59:17 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
> 
> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
> 
>     ucomiss xmm0, xmm0
>     jp      label
>     jne     label
> 
> into
> 
>     ucomiss xmm0, xmm0
>     jp      label
> 
> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
> 
>         xorl    ecx, ecx
>         ucomiss xmm0, xmm1
>         jnp     done
>         pushf
>         andq    [rsp], 0xffffff2b
>         popf
>     done:
>         movl    eax, 1
>         cmovel  eax, ecx
> 
> The patch changes this sequence into
> 
>     xorl    ecx, ecx
>     ucomiss xmm0, xmm1
>     movl    eax, 1
>     cmovpl  eax, ecx
>     cmovnel eax, ecx
> 
> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
> 
> The benchmark results are as follow:
> 
>     Before:
>     Benchmark                      Mode  Cnt     Score     Error  Units
>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  ns/op
>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  ns/op
>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  ns/op
>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  ns/op
>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  ns/op
>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  ns/op
>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  ns/op
>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  ns/op
> 
>     After:
>     Benchmark                      Mode  Cnt     Score     Error  Units
>     FPComparison.equalDouble       avgt    5   594.636 ?   8.922  ns/op
>     FPComparison.equalFloat        avgt    5   663.849 ?   3.656  ns/op
>     FPComparison.isFiniteDouble    avgt    5   518.309 ? 107.352  ns/op
>     FPComparison.isFiniteFloat     avgt    5   515.576 ?  14.669  ns/op
>     FPComparison.isInfiniteDouble  avgt    5   621.185 ?  11.935  ns/op
>     FPComparison.isInfiniteFloat   avgt    5   623.566 ?  15.206  ns/op
>     FPComparison.isNanDouble       avgt    5   400.124 ?   0.762  ns/op
>     FPComparison.isNanFloat        avgt    5   546.486 ?   1.509  ns/op
> 
> Thank you very much.

Thank you for including tests. But you need additional other float compare (not just `ea` `ne`) tests since you removed some of `Cmp` instructions.

You need approval from core libs for Java methods changes (it affects all platforms). And we will get intrinsics for them soon (I think): #8459.

Please add comments to `cmpOpU*` operands explaining changes in them.

You did not explain removal of some float compare instructions.

src/hotspot/cpu/x86/x86_64.ad line 6998:

> 6996:   ins_encode %{
> 6997:     __ cmovl(Assembler::parity, $dst$$Register, $src$$Register);
> 6998:     __ cmovl(Assembler::notEqual, $dst$$Register, $src$$Register);

Should this be `equal`?

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

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8525

From mr at openjdk.java.net  Wed May  4 20:26:40 2022
From: mr at openjdk.java.net (Mark Reinhold)
Date: Wed, 4 May 2022 20:26:40 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v6]
In-Reply-To: <vYo0UIcyKZGjaQosXWtu_MDG1TPxNz2-Oo2bfEXE_aI=.6cc54504-f465-42be-a8eb-478f9691530a@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <vYo0UIcyKZGjaQosXWtu_MDG1TPxNz2-Oo2bfEXE_aI=.6cc54504-f465-42be-a8eb-478f9691530a@github.com>
Message-ID: <nZ77xje_ad_PaRgVp_fdxLrlqM_HBYquK72hl6tBELk=.269d8ac1-0d03-4109-ac73-34ee9a52bbcc@github.com>

On Mon, 2 May 2022 20:31:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Update wording to address review feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Change punctuation from review feedback.
>  - Respond to review feedback; make sequence of values explicit.
>  - Respond to review feedback.
>  - Respond to review feedback.
>  - Respond to CSR feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Update comment in template.
>  - JDK-8285497: Add system property for Java SE specification maintenance version

Changes requested by mr (Lead).

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

PR: https://git.openjdk.java.net/jdk/pull/8437

From mr at openjdk.java.net  Wed May  4 20:26:44 2022
From: mr at openjdk.java.net (Mark Reinhold)
Date: Wed, 4 May 2022 20:26:44 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v5]
In-Reply-To: <xE9BZUJUudGTx8ZyRc9ta46majTcUA20GiGXgkMjMXE=.9c716eb4-a6ca-47a5-addb-4d094ca8f4ec@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <y6qNiLOiqAi4Lu_xZUns3fJpIGRHlf6R3jLKA5PT_pk=.9400279b-151e-4a98-94f4-a7dde932b344@github.com>
 <y1OD-59e5YmZG23i2lBodRH23_CqJXZnSoBhnpLyIEU=.10bd8612-d782-48ed-b76f-de476341b20b@github.com>
 <ComDy6I5wL37EpHF_giwqof4VNkvZzCvexm3SGukzMc=.e476bdd6-12a6-4ae0-9f8d-8dd79a20aaa4@github.com>
 <c4xaElUahQKe72pq-zI4MWvWCWObe4oMyV8z89G8GFg=.a7d8d8dd-959c-4a7d-bdc7-227c6db2e550@github.com>
 <xE9BZUJUudGTx8ZyRc9ta46majTcUA20GiGXgkMjMXE=.9c716eb4-a6ca-47a5-addb-4d094ca8f4ec@github.com>
Message-ID: <_LSz3KZBUk6tU8CZHt4Q9rn3gv-XEB2JlIHivotvvV4=.6b24d209-f24f-405d-849f-2d2f23f2ffae@github.com>

On Tue, 3 May 2022 01:20:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> In the latest push, to address the concerns raised updated the proposed wording to, in plain text:
>> 
>> Java Runtime Environment specification maintenance version, not defined before the specification implemented by this runtime has undergone a maintenance release (optional). When defined, the value of this property may be interpreted as a positive integer. The value indicates the latest maintenance release the runtime is known to support. A later release may be supported by the environment. To indicate the first maintenance release this property will have the value "1"; to indicate the second maintenance release, this property will have the value "2", and so on.
>
> PS CSR Updated to reflect this push; please review: https://bugs.openjdk.java.net/browse/JDK-8285764

The negative definition above permits the property always to be undefined, but we do want it to be defined when meaningful. It?s also getting to be an awful lot of text to add to the otherwise terse tabular summary of system properties in the [`System::getProperties()` specification](https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/System.html#getProperties()).

Consider using this text in the table:

> Java Runtime Environment specification maintenance version, which may be interpreted as a positive integer (optional, see below)

and then this in a paragraph following the table:

> The {@code java.specification.maintenance.version} property is defined if the specification implemented by this runtime at the time of its construction had undergone a <a href="https://jcp.org/en/procedures/jcp2#3.6.4">maintenance release</a>. When defined, its value identifies that maintenance release. To indicate the first maintenance release this property will have the value {@code "1"}; to indicate the second maintenance release this property will have the value {@code "2"}, and so on.

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

PR: https://git.openjdk.java.net/jdk/pull/8437

From psandoz at openjdk.java.net  Wed May  4 22:31:25 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 4 May 2022 22:31:25 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
In-Reply-To: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
Message-ID: <uHIVqB_EGvG41QVcPnw4OJML7-QZTq-kfdWZXe9G8ak=.d2cdb4da-7034-4b86-b0ad-f0da674ceb51@github.com>

On Wed, 4 May 2022 01:59:17 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
> 
> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
> 
>     ucomiss xmm0, xmm0
>     jp      label
>     jne     label
> 
> into
> 
>     ucomiss xmm0, xmm0
>     jp      label
> 
> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
> 
>         xorl    ecx, ecx
>         ucomiss xmm0, xmm1
>         jnp     done
>         pushf
>         andq    [rsp], 0xffffff2b
>         popf
>     done:
>         movl    eax, 1
>         cmovel  eax, ecx
> 
> The patch changes this sequence into
> 
>     xorl    ecx, ecx
>     ucomiss xmm0, xmm1
>     movl    eax, 1
>     cmovpl  eax, ecx
>     cmovnel eax, ecx
> 
> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
> 
> The benchmark results are as follow:
> 
>     Before:
>     Benchmark                      Mode  Cnt     Score     Error  Units
>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  ns/op
>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  ns/op
>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  ns/op
>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  ns/op
>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  ns/op
>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  ns/op
>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  ns/op
>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  ns/op
> 
>     After:
>     Benchmark                      Mode  Cnt     Score     Error  Units
>     FPComparison.equalDouble       avgt    5   594.636 ?   8.922  ns/op
>     FPComparison.equalFloat        avgt    5   663.849 ?   3.656  ns/op
>     FPComparison.isFiniteDouble    avgt    5   518.309 ? 107.352  ns/op
>     FPComparison.isFiniteFloat     avgt    5   515.576 ?  14.669  ns/op
>     FPComparison.isInfiniteDouble  avgt    5   621.185 ?  11.935  ns/op
>     FPComparison.isInfiniteFloat   avgt    5   623.566 ?  15.206  ns/op
>     FPComparison.isNanDouble       avgt    5   400.124 ?   0.762  ns/op
>     FPComparison.isNanFloat        avgt    5   546.486 ?   1.509  ns/op
> 
> Thank you very much.

The changes to `Float` and `Double` look good. I don't think we need additional tests, see test/jdk/java/lang/Math/IeeeRecommendedTests.java.

At first i thought we no longer need PR #8459 but it seems both PRs are complimentary, albeit PR #8459 has more modest performance gains for the intrinsics.

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

PR: https://git.openjdk.java.net/jdk/pull/8525

From darcy at openjdk.java.net  Wed May  4 23:10:06 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 4 May 2022 23:10:06 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v7]
In-Reply-To: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
Message-ID: <DYlMy7YjEc26N4Sq1LafEauWien3fh3SUY0w6FxNXaY=.5595ded0-3e3c-4ec3-a5bb-0d1455509ef0@github.com>

> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
> 
> I'll update copyright years before an integration.

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

 - Respond to mbreinhold review feedback.
 - Merge branch 'master' into JDK-8285497
 - Update wording to address review feedback.
 - Merge branch 'master' into JDK-8285497
 - Change punctuation from review feedback.
 - Respond to review feedback; make sequence of values explicit.
 - Respond to review feedback.
 - Respond to review feedback.
 - Respond to CSR feedback.
 - Merge branch 'master' into JDK-8285497
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f4e6f016...7b7720cf

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8437/files
  - new: https://git.openjdk.java.net/jdk/pull/8437/files/741ececa..7b7720cf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=05-06

  Stats: 7420 lines in 158 files changed: 4834 ins; 1036 del; 1550 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437

PR: https://git.openjdk.java.net/jdk/pull/8437

From darcy at openjdk.java.net  Wed May  4 23:10:09 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 4 May 2022 23:10:09 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v6]
In-Reply-To: <vYo0UIcyKZGjaQosXWtu_MDG1TPxNz2-Oo2bfEXE_aI=.6cc54504-f465-42be-a8eb-478f9691530a@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <vYo0UIcyKZGjaQosXWtu_MDG1TPxNz2-Oo2bfEXE_aI=.6cc54504-f465-42be-a8eb-478f9691530a@github.com>
Message-ID: <g-LmDM3Kx-orzZynGaXa7Tg6ZNTAwKYaw80daAj3yyA=.c6b970e2-20bb-4029-997f-6b64a2d452c2@github.com>

On Mon, 2 May 2022 20:31:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Update wording to address review feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Change punctuation from review feedback.
>  - Respond to review feedback; make sequence of values explicit.
>  - Respond to review feedback.
>  - Respond to review feedback.
>  - Respond to CSR feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Update comment in template.
>  - JDK-8285497: Add system property for Java SE specification maintenance version

PR and CSR updated as suggested.

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

PR: https://git.openjdk.java.net/jdk/pull/8437

From kvn at openjdk.java.net  Wed May  4 23:20:18 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 4 May 2022 23:20:18 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
In-Reply-To: <KdpuTVQMeytKodsxscUf6bY-Rb9ZX1mh-JlqxGz3yhc=.ad30bd97-86fe-4ae8-80ff-277eacce88d9@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <KdpuTVQMeytKodsxscUf6bY-Rb9ZX1mh-JlqxGz3yhc=.ad30bd97-86fe-4ae8-80ff-277eacce88d9@github.com>
Message-ID: <6hRgLEWJfB8OHOYNJReUaMac469hvDuemoURK-aMy4Y=.963b7561-33e0-4069-8d89-8b447d4e0f0f@github.com>

On Wed, 4 May 2022 19:32:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi,
>> 
>> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
>> 
>> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>>     jne     label
>> 
>> into
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>> 
>> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
>> 
>>         xorl    ecx, ecx
>>         ucomiss xmm0, xmm1
>>         jnp     done
>>         pushf
>>         andq    [rsp], 0xffffff2b
>>         popf
>>     done:
>>         movl    eax, 1
>>         cmovel  eax, ecx
>> 
>> The patch changes this sequence into
>> 
>>     xorl    ecx, ecx
>>     ucomiss xmm0, xmm1
>>     movl    eax, 1
>>     cmovpl  eax, ecx
>>     cmovnel eax, ecx
>> 
>> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
>> 
>> The benchmark results are as follow:
>> 
>>     Before:
>>     Benchmark                      Mode  Cnt     Score     Error  Units
>>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  ns/op
>>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  ns/op
>>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  ns/op
>>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  ns/op
>>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  ns/op
>>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  ns/op
>>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  ns/op
>>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  ns/op
>> 
>>     After:
>>     Benchmark                      Mode  Cnt     Score     Error  Units
>>     FPComparison.equalDouble       avgt    5   594.636 ?   8.922  ns/op
>>     FPComparison.equalFloat        avgt    5   663.849 ?   3.656  ns/op
>>     FPComparison.isFiniteDouble    avgt    5   518.309 ? 107.352  ns/op
>>     FPComparison.isFiniteFloat     avgt    5   515.576 ?  14.669  ns/op
>>     FPComparison.isInfiniteDouble  avgt    5   621.185 ?  11.935  ns/op
>>     FPComparison.isInfiniteFloat   avgt    5   623.566 ?  15.206  ns/op
>>     FPComparison.isNanDouble       avgt    5   400.124 ?   0.762  ns/op
>>     FPComparison.isNanFloat        avgt    5   546.486 ?   1.509  ns/op
>> 
>> Thank you very much.
>
> src/hotspot/cpu/x86/x86_64.ad line 6998:
> 
>> 6996:   ins_encode %{
>> 6997:     __ cmovl(Assembler::parity, $dst$$Register, $src$$Register);
>> 6998:     __ cmovl(Assembler::notEqual, $dst$$Register, $src$$Register);
> 
> Should this be `equal`?

I see that you swapped `src, dst` in `match()` but `format` is sill incorrect and the code is confusing.

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

PR: https://git.openjdk.java.net/jdk/pull/8525

From mcimadamore at openjdk.java.net  Wed May  4 23:24:29 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 23:24:29 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
Message-ID: <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>

On Wed, 4 May 2022 16:47:28 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits:
>> 
>>  - Merge branch 'master' into foreign-preview
>>  - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Tweak support for Linker lookup
>>    Improve javadoc of SymbolLookup
>>  - Tweak Addressable javadoc
>>  - Downcall and upcall tests use wrong layout which is missing some trailing padding
>>  - Simplify libraryLookup impl
>>  - Address CSR comments
>>  - Merge branch 'master' into foreign-preview
>>  - Add ValueLayout changes
>>  - Tweak support for array element var handle
>>  - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab
>
> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153:
> 
>> 151:     static SymbolLookup loaderLookup() {
>> 152:         Class<?> caller = Reflection.getCallerClass();
>> 153:         ClassLoader loader = Objects.requireNonNull(caller.getClassLoader());
> 
> Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]?
> 
> [^1]: This?happens when?`caller` is?on the?bootstrap?classpath.
> [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack.

Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm?

As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class).

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Wed May  4 23:30:35 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 23:30:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v38]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <lTPkMd6NbMrGw592RcSdVDv5aZy5f24Akl5N_K1qtyI=.f9b760d0-e5aa-4113-812c-3ff704274704@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

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

  Tweak examples in SymbolLookup javadoc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/41d055ab..853f06b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=37
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=36-37

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From kvn at openjdk.java.net  Wed May  4 23:31:19 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 4 May 2022 23:31:19 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
In-Reply-To: <uHIVqB_EGvG41QVcPnw4OJML7-QZTq-kfdWZXe9G8ak=.d2cdb4da-7034-4b86-b0ad-f0da674ceb51@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <uHIVqB_EGvG41QVcPnw4OJML7-QZTq-kfdWZXe9G8ak=.d2cdb4da-7034-4b86-b0ad-f0da674ceb51@github.com>
Message-ID: <aDeexKQXmUKFtVEoRE3yA0H9j1crX92ZGyzEryIzjdA=.48fc5efc-f783-42cc-9cc9-3e0db66aeeda@github.com>

On Wed, 4 May 2022 22:27:48 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The changes to `Float` and `Double` look good. I don't think we need additional tests, see test/jdk/java/lang/Math/IeeeRecommendedTests.java.

Thank you, Paul for pointing the test. It means we need to run tier4 (which runs these tests with -Xcomp) to make sure methods are compiled by C2.

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

PR: https://git.openjdk.java.net/jdk/pull/8525

From mcimadamore at openjdk.java.net  Wed May  4 23:32:49 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 23:32:49 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
 <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
Message-ID: <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>

On Wed, 4 May 2022 23:20:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153:
>> 
>>> 151:     static SymbolLookup loaderLookup() {
>>> 152:         Class<?> caller = Reflection.getCallerClass();
>>> 153:         ClassLoader loader = Objects.requireNonNull(caller.getClassLoader());
>> 
>> Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]?
>> 
>> [^1]: This?happens when?`caller` is?on the?bootstrap?classpath.
>> [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack.
>
> Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm?
> 
> As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class).

Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module.

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Wed May  4 23:47:30 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 4 May 2022 23:47:30 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
 <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
 <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>
Message-ID: <Z2i25iT-dN2Zez6f6Azb3Xc1UGLGiuSZ_rp5RWSbQMo=.7a902992-b630-452f-aa93-4c1b6ddadf74@github.com>

On Wed, 4 May 2022 23:29:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm?
>> 
>> As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class).
>
> Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module.

Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe.

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From xgong at openjdk.java.net  Thu May  5 01:15:30 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 01:15:30 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <jzpIE3s42ERAX7_TFnI-bak5zTxw9pyFLbr-fLjRIC8=.84018837-68fb-4a90-a14b-924f58cec3d8@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
 <jzpIE3s42ERAX7_TFnI-bak5zTxw9pyFLbr-fLjRIC8=.84018837-68fb-4a90-a14b-924f58cec3d8@github.com>
Message-ID: <vS7KxR4t7OJyPfvUROBgDl_UX2AUrdVDDnWc7nCgLv8=.c67f9227-dda2-4d0a-b848-737bc441051a@github.com>

On Fri, 29 Apr 2022 21:34:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename the "usePred" to "offsetInRange"
>
> IIUC when the hardware does not support predicated loads then any false `offsetIntRange` value causes the load intrinsic to fail resulting in the fallback, so it would not be materially any different to the current behavior, just more uniformly implemented.
> 
> Why can't the intrinsic support the passing a boolean directly? Is it something to do with constants? If that is not possible I recommend creating named constant values and pass those all the way through rather than converting a boolean to an integer value. Then there is no need for a branch checking `offsetInRange`.
> 
> Might be better to hold off until the JEP is integrated and then update, since this will conflict (`byte[]` and `ByteBuffer` load methods are removed and `MemorySegment` load methods are added). You could prepare for that now by branching off `vectorIntrinsics`.

Thanks for your comments @PaulSandoz !

> IIUC when the hardware does not support predicated loads then any false `offsetIntRange` value causes the load intrinsic to fail resulting in the fallback, so it would not be materially any different to the current behavior, just more uniformly implemented.

Yes, it's true that this patch doesn't have any different to the hardware that does not support the predicated loads. It only benefits the predicated feature supported systems like ARM SVE and X86 AVX-512.

> Why can't the intrinsic support the passing a boolean directly? Is it something to do with constants? If that is not possible I recommend creating named constant values and pass those all the way through rather than converting a boolean to an integer value. Then there is no need for a branch checking offsetInRange.

Yeah, I agree that it's not good by adding a branch checking for `offsetInRange`. But actually I met the constant issue that passing the values all the way cannot guarantee the argument a constant in compiler at the compile time. Do you have any better idea to fixing this?

> Might be better to hold off until the JEP is integrated and then update, since this will conflict (byte[] and ByteBuffer load methods are removed and MemorySegment load methods are added). You could prepare for that now by branching off vectorIntrinsics.

Agree. Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From psandoz at openjdk.java.net  Thu May  5 01:25:29 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 5 May 2022 01:25:29 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <vS7KxR4t7OJyPfvUROBgDl_UX2AUrdVDDnWc7nCgLv8=.c67f9227-dda2-4d0a-b848-737bc441051a@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
 <jzpIE3s42ERAX7_TFnI-bak5zTxw9pyFLbr-fLjRIC8=.84018837-68fb-4a90-a14b-924f58cec3d8@github.com>
 <vS7KxR4t7OJyPfvUROBgDl_UX2AUrdVDDnWc7nCgLv8=.c67f9227-dda2-4d0a-b848-737bc441051a@github.com>
Message-ID: <IAVTQdQHMb1BmccXLzKeIFA3OcZF11MUBlGJb8IABGo=.0dae370f-a8af-479f-b4a3-cdbfb7347dfb@github.com>

On Thu, 5 May 2022 01:13:23 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Yeah, I agree that it's not good by adding a branch checking for `offsetInRange`. But actually I met the constant issue that passing the values all the way cannot guarantee the argument a constant in compiler at the compile time. Do you have any better idea to fixing this?

That's odd, `boolean` constants are passed that are then converted to `int` constants.
Did you try passing integer constants all the way through?

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From naoto at openjdk.java.net  Thu May  5 01:42:27 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 May 2022 01:42:27 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v4]
In-Reply-To: <1dZ6o94-xt1oOEevAAO3uYDQrjStchH0FfrHi88V1OE=.bbc63a8f-7959-46fa-ad9c-292c09e80ae5@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <1dZ6o94-xt1oOEevAAO3uYDQrjStchH0FfrHi88V1OE=.bbc63a8f-7959-46fa-ad9c-292c09e80ae5@github.com>
Message-ID: <tRSCLtwhcT3K3Cdy8VZC4qQGS33-Uss4jEUZNlfjeHw=.4a38432f-8fb3-4ad3-9cb4-906f2ceea673@github.com>

On Wed, 4 May 2022 17:09:32 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 73:

> 71:         @SuppressWarnings("removal")
> 72:         String jnuEncoding = AccessController.doPrivileged((PrivilegedAction<String>) ()
> 73:             -> System.getProperty("sun.jnu.encoding"));

No need to issue `doPrivileged()`, which is deprecated

src/java.base/unix/classes/java/lang/ProcessImpl.java line 149:

> 147:         @SuppressWarnings("removal")
> 148:         String jnuEncoding = AccessController.doPrivileged((PrivilegedAction<String>) ()
> 149:             -> System.getProperty("sun.jnu.encoding"));

Same here.

test/jdk/java/lang/System/i18nEnvArg.java line 70:

> 68:             Map<String, String> environ = pb.environment();
> 69:             environ.clear();
> 70:             environ.put("LANG", "ja_JP.eucjp");

There are many duplicate pieces of code here and in the `else` block below. Can you simplify this `if` statement more?

test/jdk/java/lang/System/i18nEnvArg.java line 110:

> 108:             String s = System.getenv(EUC_JP_TEXT);
> 109:             ByteArrayOutputStream baos = new ByteArrayOutputStream();
> 110:             PrintStream ps = new PrintStream(baos);

Can utilize try-with-resources pattern.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From xgong at openjdk.java.net  Thu May  5 01:46:19 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 01:46:19 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <IAVTQdQHMb1BmccXLzKeIFA3OcZF11MUBlGJb8IABGo=.0dae370f-a8af-479f-b4a3-cdbfb7347dfb@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
 <jzpIE3s42ERAX7_TFnI-bak5zTxw9pyFLbr-fLjRIC8=.84018837-68fb-4a90-a14b-924f58cec3d8@github.com>
 <vS7KxR4t7OJyPfvUROBgDl_UX2AUrdVDDnWc7nCgLv8=.c67f9227-dda2-4d0a-b848-737bc441051a@github.com>
 <IAVTQdQHMb1BmccXLzKeIFA3OcZF11MUBlGJb8IABGo=.0dae370f-a8af-479f-b4a3-cdbfb7347dfb@github.com>
Message-ID: <KiP-y30eUj5JCrxvN-FjDpDPJO00WC-Fx33A4t3Zi4o=.a31ea532-539f-4929-b612-5c7ab0ea01fa@github.com>

On Thu, 5 May 2022 01:21:40 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > Yeah, I agree that it's not good by adding a branch checking for `offsetInRange`. But actually I met the constant issue that passing the values all the way cannot guarantee the argument a constant in compiler at the compile time. Do you have any better idea to fixing this?
> 
> That's odd, `boolean` constants are passed that are then converted to `int` constants. Did you try passing integer constants all the way through?

I will try again. I remember the main cause is the calling of `fromArray0` from `fromArray`, it is not annotated with `ForceInline`. The arguments might not be compiled to a constant for cases that the offset is not in the array range like tail loop.

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Thu May  5 01:55:19 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 01:55:19 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <KiP-y30eUj5JCrxvN-FjDpDPJO00WC-Fx33A4t3Zi4o=.a31ea532-539f-4929-b612-5c7ab0ea01fa@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
 <jzpIE3s42ERAX7_TFnI-bak5zTxw9pyFLbr-fLjRIC8=.84018837-68fb-4a90-a14b-924f58cec3d8@github.com>
 <vS7KxR4t7OJyPfvUROBgDl_UX2AUrdVDDnWc7nCgLv8=.c67f9227-dda2-4d0a-b848-737bc441051a@github.com>
 <IAVTQdQHMb1BmccXLzKeIFA3OcZF11MUBlGJb8IABGo=.0dae370f-a8af-479f-b4a3-cdbfb7347dfb@github.com>
 <KiP-y30eUj5JCrxvN-FjDpDPJO00WC-Fx33A4t3Zi4o=.a31ea532-539f-4929-b612-5c7ab0ea01fa@github.com>
Message-ID: <mMJYVVy3lIVSi7h6yzMGMyEPkrnMPkiBdpMZIpwynPo=.5e105ffc-edf6-4bcd-ace4-7713435da347@github.com>

On Thu, 5 May 2022 01:42:48 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > > Yeah, I agree that it's not good by adding a branch checking for `offsetInRange`. But actually I met the constant issue that passing the values all the way cannot guarantee the argument a constant in compiler at the compile time. Do you have any better idea to fixing this?
> > 
> > 
> > That's odd, `boolean` constants are passed that are then converted to `int` constants. Did you try passing integer constants all the way through?
> 
> I will try again. I remember the main cause is the calling of `fromArray0` from `fromArray`, it is not annotated with `ForceInline`. The arguments might not be compiled to a constant for cases that the offset is not in the array range like tail loop.

I tried to pass the integer constant all the way, and unfortunate that the `offsetInRange` is not compiled to a constant. The following assertion in the `vectorIntrinsics.cpp` will fail:

  --- a/src/hotspot/share/opto/vectorIntrinsics.cpp
+++ b/src/hotspot/share/opto/vectorIntrinsics.cpp
@@ -1236,6 +1236,7 @@ bool LibraryCallKit::inline_vector_mem_masked_operation(bool is_store) {
     } else {
       // Masked vector load with IOOBE always uses the predicated load.
       const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int();
+      assert(offset_in_range->is_con(), "not a constant");
       if (!offset_in_range->is_con()) {
         if (C->print_intrinsics()) {
           tty->print_cr("  ** missing constant: offsetInRange=%s",

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Thu May  5 02:08:14 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 02:08:14 GMT
Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated
 architectures
Message-ID: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>

Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with:


 1) mem_v = load(addr)     ; non-masked load from the same memory
 2) v = blend(mem_v, v, m) ; blend with the src vector with the mask
 3) store(addr, v)         ; non-masked store into the memory


Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API.

Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`:

Benchmark                                  before    after   Units
StoreMaskedBenchmark.byteStoreArrayMask   221.733  11094.126 ops/ms
StoreMaskedBenchmark.doubleStoreArrayMask  41.086   1034.408 ops/ms
StoreMaskedBenchmark.floatStoreArrayMask   73.820   1985.015 ops/ms
StoreMaskedBenchmark.intStoreArrayMask     75.028   2027.557 ops/ms
StoreMaskedBenchmark.longStoreArrayMask    40.929   1032.928 ops/ms
StoreMaskedBenchmark.shortStoreArrayMask  135.794   5307.567 ops/ms

Similar performance gain can also be observed on ARM NEON system.

And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`:

Benchmark                                  before     after   Units
StoreMaskedBenchmark.byteStoreArrayMask   11185.956 21012.824 ops/ms
StoreMaskedBenchmark.doubleStoreArrayMask  1480.644  3911.720 ops/ms
StoreMaskedBenchmark.floatStoreArrayMask   2738.352  7708.365 ops/ms
StoreMaskedBenchmark.intStoreArrayMask     4191.904  9300.428 ops/ms
StoreMaskedBenchmark.longStoreArrayMask    2025.031  4604.504 ops/ms
StoreMaskedBenchmark.shortStoreArrayMask   8339.389 17817.128 ops/ms

Similar performance gain can also be observed on ARM SVE system.

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

Depends on: https://git.openjdk.java.net/jdk/pull/8035

Commit messages:
 - 8284050: [vectorapi] Optimize masked store for non-predicated architectures
 - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature

Changes: https://git.openjdk.java.net/jdk/pull/8544/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8544&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284050
  Stats: 1708 lines in 44 files changed: 710 ins; 188 del; 810 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8544.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8544/head:pull/8544

PR: https://git.openjdk.java.net/jdk/pull/8544

From xgong at openjdk.java.net  Thu May  5 02:09:39 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 02:09:39 GMT
Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated
 architectures [v2]
In-Reply-To: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
References: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
Message-ID: <B8DYwlRUNusrIQc-RcJ6OmPn0mYEOiytmgFf9q8j9Vc=.8930f40a-e383-4ac9-8d14-697147f22e02@github.com>

> Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with:
> 
> 
>  1) mem_v = load(addr)     ; non-masked load from the same memory
>  2) v = blend(mem_v, v, m) ; blend with the src vector with the mask
>  3) store(addr, v)         ; non-masked store into the memory
> 
> 
> Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API.
> 
> Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`:
> 
> Benchmark                                  before    after   Units
> StoreMaskedBenchmark.byteStoreArrayMask   221.733  11094.126 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  41.086   1034.408 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   73.820   1985.015 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     75.028   2027.557 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    40.929   1032.928 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask  135.794   5307.567 ops/ms
> 
> Similar performance gain can also be observed on ARM NEON system.
> 
> And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`:
> 
> Benchmark                                  before     after   Units
> StoreMaskedBenchmark.byteStoreArrayMask   11185.956 21012.824 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  1480.644  3911.720 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   2738.352  7708.365 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     4191.904  9300.428 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    2025.031  4604.504 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask   8339.389 17817.128 ops/ms
> 
> Similar performance gain can also be observed on ARM SVE system.

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

  8284050: [vectorapi] Optimize masked store for non-predicated architectures

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

Changes: https://git.openjdk.java.net/jdk/pull/8544/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8544&range=01
  Stats: 915 lines in 43 files changed: 405 ins; 80 del; 430 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8544.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8544/head:pull/8544

PR: https://git.openjdk.java.net/jdk/pull/8544

From xgong at openjdk.java.net  Thu May  5 02:17:20 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 02:17:20 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <Zs4vCQJvlQMoBVVbQ-EWeIad-aN48Gddsh-ft51_6PQ=.01b18a0c-b15e-4791-95be-895a413080f0@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
 <Zs4vCQJvlQMoBVVbQ-EWeIad-aN48Gddsh-ft51_6PQ=.01b18a0c-b15e-4791-95be-895a413080f0@github.com>
Message-ID: <CqeQUhahiO7s0utUXnwKFO0z96hNbENK6J8qgKeA9oo=.0f502361-d551-4e36-a0e5-10618bb75f9e@github.com>

On Thu, 28 Apr 2022 00:13:49 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename the "usePred" to "offsetInRange"
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1232:
> 
>> 1230:   // out when current case uses the predicate feature.
>> 1231:   if (!supports_predicate) {
>> 1232:     bool use_predicate = false;
> 
> If we rename this to needs_predicate it will be easier to understand.

Thanks for the comment! This local variable will be removed after adding the similar intrinsify for store masked. Please help to see the PR https://github.com/openjdk/jdk/pull/8544. Thanks so much!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Thu May  5 02:17:20 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 02:17:20 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <8Yu4J-PCYFJtBXrfgWoCbaR-7QZTXH4IzmXOf_lk164=.66071c45-1f1a-4931-a414-778f353c7e83@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <qGT_pT7bJXtmGLdET7zfdn61OCP6K0qO3druyXapADc=.86ab137e-49d0-437c-ae54-90370c270ef6@github.com>
 <35S4J_r9jBw_-SAow2oMYaSsTvubhSmZFVPb_VM6KEg=.7feff8fa-6e20-453e-aed6-e53c7d9beaad@github.com>
 <8Yu4J-PCYFJtBXrfgWoCbaR-7QZTXH4IzmXOf_lk164=.66071c45-1f1a-4931-a414-778f353c7e83@github.com>
Message-ID: <BZ_Ya8ilkfC5StN3JCXjAQJwMwGwPpKanHVnlFEff3U=.6b30f25a-9b77-428c-9897-909dd8d59118@github.com>

On Thu, 31 Mar 2022 02:15:26 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> I'm afraid not. "Load + Blend" makes the elements of unmasked lanes to be `0`. Then a full store may change the values in the unmasked memory to be 0, which is different with the mask store API definition.
>
> The blend should be with the intended-to-store vector, so that masked lanes contain the need-to-store elements and unmasked lanes contain the loaded elements, which would be stored back, which results in unchanged values.

Hi @merykitty @jatin-bhateja , could you please help to take a review at the similar store masked PR https://github.com/openjdk/jdk/pull/8544 ? Any feedback is welcome! Thanks so much!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From sspitsyn at openjdk.java.net  Thu May  5 02:25:12 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 5 May 2022 02:25:12 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
Message-ID: <obecW-tlrdGOcntvR3ze475nlAw-kj12CKCVF-b_JlI=.3e70ef85-3112-416a-8cf5-978ced099032@github.com>

On Wed, 4 May 2022 12:12:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1
>  - Merge with jdk-19+19
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75

I've completed review of new vthread-related tests in the folder serviceability/jvmti.
It includes sub-folders:
 serviceability/jvmti/events
 serviceability/jvmti/negative
 serviceability/jvmti/thread
Thank you, Leonid, for resolving my comments!

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From jrose at openjdk.java.net  Thu May  5 02:45:17 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Thu, 5 May 2022 02:45:17 GMT
Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated
 architectures [v2]
In-Reply-To: <B8DYwlRUNusrIQc-RcJ6OmPn0mYEOiytmgFf9q8j9Vc=.8930f40a-e383-4ac9-8d14-697147f22e02@github.com>
References: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
 <B8DYwlRUNusrIQc-RcJ6OmPn0mYEOiytmgFf9q8j9Vc=.8930f40a-e383-4ac9-8d14-697147f22e02@github.com>
Message-ID: <K9t8_BlVfVNeyw9IXz9HjPWsR_I5JAweB09Rrl6Qkg4=.6a7994b6-fd97-4cc8-8f98-4a5855074a06@github.com>

On Thu, 5 May 2022 02:09:39 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with:
>> 
>> 
>>  1) mem_v = load(addr)     ; non-masked load from the same memory
>>  2) v = blend(mem_v, v, m) ; blend with the src vector with the mask
>>  3) store(addr, v)         ; non-masked store into the memory
>> 
>> 
>> Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API.
>> 
>> Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`:
>> 
>> Benchmark                                  before    after   Units
>> StoreMaskedBenchmark.byteStoreArrayMask   221.733  11094.126 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  41.086   1034.408 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   73.820   1985.015 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     75.028   2027.557 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    40.929   1032.928 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask  135.794   5307.567 ops/ms
>> 
>> Similar performance gain can also be observed on ARM NEON system.
>> 
>> And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`:
>> 
>> Benchmark                                  before     after   Units
>> StoreMaskedBenchmark.byteStoreArrayMask   11185.956 21012.824 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  1480.644  3911.720 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   2738.352  7708.365 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     4191.904  9300.428 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    2025.031  4604.504 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask   8339.389 17817.128 ops/ms
>> 
>> Similar performance gain can also be observed on ARM SVE system.
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8284050: [vectorapi] Optimize masked store for non-predicated architectures

The JIT (in all other circumstances AFAIK) never produces "phantom stores", stores into Java variables which are not specified as the target of a JVM store instruction (putfield, dastore, etc.).  The fact that a previously-read value is used by the phantom store does not make it any better.

Yes, the memory states may be correct after the blend and store is done, but the effect on the Java Memory Model is to issue the extra phantom stores of the unselected array elements.  Under certain circumstances, this will create race conditions after the optimization where there were no race conditions before the optimization.  Other threads could (under Java Memory Model rules) witness the effects of the phantom stores.  If the Java program is properly synchronized, the introduction of an illegitimate race condition can cause another thread, now in an illegal race, to see an old value in a variable (the recopied unselected array element) which the JMM says is impossible.

Yes, this only shows up in multi-threaded programs, and ones where two threads step on one array, but Java is a multi-threaded language, and it must conform to its own specification as such.

This blend technique would be very reasonable if there is no race condition.  (Except at the very beginning or end of arrays.)  And the JMM leaves room for many optimizations.  And yet I think this is a step too far.  I'd like to be wrong about this, but I don't think I am.

So, I think you need to use a different technique, other than blend-and-unpredicated-store, for masked stores on non-predicated architectures.

For example, you could simulate a masked store instruction on an architecture that supports scatter (scattering values of the array type).  Do this by setting up two vectors of machine pointers.  One vector points to each potentially-affected element of the array (some kind of index computation plus a scaled iota vector).  The other vector is set up similarly, but points into a fixed-sized, thread-local buffer, what I would call the "bit bucket".  Blend the addresses, and then scatter, so that selected array lanes are updated, and unselected values are sent to the "bit bucket".

This is complex enough (and platform-dependent enough) that you probably need to write a hand-coded assembly language subroutine, to call from the JIT code.  Sort of like the arraycopy stubs.

It's even more work than the proposed patch here, but it's the right thing, I'm afraid.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1363:

> 1361:       // Use the vector blend to implement the masked store. The biased elements are the original
> 1362:       // values in the memory.
> 1363:       Node* mem_val = gvn().transform(LoadVectorNode::make(0, control(), memory(addr), addr, addr_type, mem_num_elem, mem_elem_bt));

I'm sorry to say it, but I am pretty sure this is an invalid optimization.
See top-level comment for more details.

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

Changes requested by jrose (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8544

From hboehm at google.com  Thu May  5 03:15:10 2022
From: hboehm at google.com (Hans Boehm)
Date: Wed, 4 May 2022 20:15:10 -0700
Subject: RFR: 8284050: [vectorapi] Optimize masked store for
 non-predicated architectures
In-Reply-To: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
References: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
Message-ID: <CAMOCf+gDSYSaEd3Q25k-Az_AztAe-2iYwR9uzyNpaeG+38TtVw@mail.gmail.com>

Naive question: What happens if one of the vector elements that should not
have been updated is concurrently being written by another thread? Aren't
you generating writes to vector elements that should not have been written?

Hans

On Wed, May 4, 2022 at 7:08 PM Xiaohong Gong <xgong at openjdk.java.net> wrote:

> Currently the vectorization of masked vector store is implemented by the
> masked store instruction only on architectures that support the predicate
> feature. The compiler will fall back to the java scalar code for
> non-predicate supported architectures like ARM NEON. However, for these
> systems, the masked store can be vectorized with the non-masked vector
> `"load + blend + store"`. For example, storing a vector` "v"` controlled by
> a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")`
> can be implemented with:
>
>
>  1) mem_v = load(addr)     ; non-masked load from the same memory
>  2) v = blend(mem_v, v, m) ; blend with the src vector with the mask
>  3) store(addr, v)         ; non-masked store into the memory
>
>
> Since the first full loading needs the array offset must be inside of the
> valid array bounds, we make the compiler do the vectorization only when the
> offset is in range of the array boundary. And the compiler will still fall
> back to the java scalar code if not all offsets are valid. Besides, the
> original offset check for masked lanes are only applied when the offset is
> not always inside of the array range. This also improves the performance
> for masked store when the offset is always valid. The whole process is
> similar to the masked load API.
>
> Here is the performance data for the masked vector store benchmarks on a
> X86 non avx-512 system, which improves about `20x ~ 50x`:
>
> Benchmark                                  before    after   Units
> StoreMaskedBenchmark.byteStoreArrayMask   221.733  11094.126 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  41.086   1034.408 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   73.820   1985.015 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     75.028   2027.557 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    40.929   1032.928 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask  135.794   5307.567 ops/ms
>
> Similar performance gain can also be observed on ARM NEON system.
>
> And here is the performance data on X86 avx-512 system, which improves
> about `1.88x - 2.81x`:
>
> Benchmark                                  before     after   Units
> StoreMaskedBenchmark.byteStoreArrayMask   11185.956 21012.824 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  1480.644  3911.720 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   2738.352  7708.365 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     4191.904  9300.428 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    2025.031  4604.504 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask   8339.389 17817.128 ops/ms
>
> Similar performance gain can also be observed on ARM SVE system.
>
> -------------
>
> Depends on: https://git.openjdk.java.net/jdk/pull/8035
>
> Commit messages:
>  - 8284050: [vectorapi] Optimize masked store for non-predicated
> architectures
>  - 8283667: [vectorapi] Vectorization for masked load with IOOBE with
> predicate feature
>
> Changes: https://git.openjdk.java.net/jdk/pull/8544/files
>  Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8544&range=00
>   Issue: https://bugs.openjdk.java.net/browse/JDK-8284050
>   Stats: 1708 lines in 44 files changed: 710 ins; 188 del; 810 mod
>   Patch: https://git.openjdk.java.net/jdk/pull/8544.diff
>   Fetch: git fetch https://git.openjdk.java.net/jdk
> pull/8544/head:pull/8544
>
> PR: https://git.openjdk.java.net/jdk/pull/8544
>

From xgong at openjdk.java.net  Thu May  5 03:21:25 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 03:21:25 GMT
Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated
 architectures [v2]
In-Reply-To: <K9t8_BlVfVNeyw9IXz9HjPWsR_I5JAweB09Rrl6Qkg4=.6a7994b6-fd97-4cc8-8f98-4a5855074a06@github.com>
References: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
 <B8DYwlRUNusrIQc-RcJ6OmPn0mYEOiytmgFf9q8j9Vc=.8930f40a-e383-4ac9-8d14-697147f22e02@github.com>
 <K9t8_BlVfVNeyw9IXz9HjPWsR_I5JAweB09Rrl6Qkg4=.6a7994b6-fd97-4cc8-8f98-4a5855074a06@github.com>
Message-ID: <2nHlMA_m35Al9nbcBILE63XcB63XuSWI_RbcUC96-As=.4fe30c48-52ab-4995-b0a1-f327009aa8a8@github.com>

On Thu, 5 May 2022 02:27:03 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8284050: [vectorapi] Optimize masked store for non-predicated architectures
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1363:
> 
>> 1361:       // Use the vector blend to implement the masked store. The biased elements are the original
>> 1362:       // values in the memory.
>> 1363:       Node* mem_val = gvn().transform(LoadVectorNode::make(0, control(), memory(addr), addr, addr_type, mem_num_elem, mem_elem_bt));
> 
> I'm sorry to say it, but I am pretty sure this is an invalid optimization.
> See top-level comment for more details.

Thanks for your comments! Yeah, this actually influences something due to the Java Memory Model rules which I missed to consider more. I will try the scatter ways instead. Thanks so much!

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

PR: https://git.openjdk.java.net/jdk/pull/8544

From xgong at openjdk.java.net  Thu May  5 03:29:16 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 03:29:16 GMT
Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated
 architectures [v2]
In-Reply-To: <B8DYwlRUNusrIQc-RcJ6OmPn0mYEOiytmgFf9q8j9Vc=.8930f40a-e383-4ac9-8d14-697147f22e02@github.com>
References: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
 <B8DYwlRUNusrIQc-RcJ6OmPn0mYEOiytmgFf9q8j9Vc=.8930f40a-e383-4ac9-8d14-697147f22e02@github.com>
Message-ID: <4k-ZTE8Uax5vrH9GMAc2MJClnaIc4zB9vteafm24S44=.e1f50cc8-3020-4091-831f-e5fa2b623f7a@github.com>

On Thu, 5 May 2022 02:09:39 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with:
>> 
>> 
>>  1) mem_v = load(addr)     ; non-masked load from the same memory
>>  2) v = blend(mem_v, v, m) ; blend with the src vector with the mask
>>  3) store(addr, v)         ; non-masked store into the memory
>> 
>> 
>> Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API.
>> 
>> Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`:
>> 
>> Benchmark                                  before    after   Units
>> StoreMaskedBenchmark.byteStoreArrayMask   221.733  11094.126 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  41.086   1034.408 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   73.820   1985.015 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     75.028   2027.557 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    40.929   1032.928 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask  135.794   5307.567 ops/ms
>> 
>> Similar performance gain can also be observed on ARM NEON system.
>> 
>> And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`:
>> 
>> Benchmark                                  before     after   Units
>> StoreMaskedBenchmark.byteStoreArrayMask   11185.956 21012.824 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  1480.644  3911.720 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   2738.352  7708.365 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     4191.904  9300.428 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    2025.031  4604.504 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask   8339.389 17817.128 ops/ms
>> 
>> Similar performance gain can also be observed on ARM SVE system.
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8284050: [vectorapi] Optimize masked store for non-predicated architectures

> _Mailing list message from [Hans Boehm](mailto:hboehm at google.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> 
> Naive question: What happens if one of the vector elements that should not have been updated is concurrently being written by another thread? Aren't you generating writes to vector elements that should not have been written?
> 
> Hans
> 
> On Wed, May 4, 2022 at 7:08 PM Xiaohong Gong <xgong at openjdk.java.net> wrote:

Yeah, this is the similar concern with what @rose00 mentioned above. The current solution cannot work well for multi-thread progresses. I will consider other better solutions. Thanks for the comments!

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3483:

> 3481:             ByteSpecies vsp = vspecies();
> 3482:             if (offset >= 0 && offset <= (a.length - vsp.length())) {
> 3483:                 intoBooleanArray0(a, offset, m, /* offsetInRange */ true);

The offset check could save the `checkMaskFromIndexSize`  for cases that offset are in the valid array bounds, which also improves the performance. @rose00 , do you think this part of change is ok at least? Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8544

From jbhateja at openjdk.java.net  Thu May  5 04:38:24 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 5 May 2022 04:38:24 GMT
Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated
 architectures [v2]
In-Reply-To: <2nHlMA_m35Al9nbcBILE63XcB63XuSWI_RbcUC96-As=.4fe30c48-52ab-4995-b0a1-f327009aa8a8@github.com>
References: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
 <B8DYwlRUNusrIQc-RcJ6OmPn0mYEOiytmgFf9q8j9Vc=.8930f40a-e383-4ac9-8d14-697147f22e02@github.com>
 <K9t8_BlVfVNeyw9IXz9HjPWsR_I5JAweB09Rrl6Qkg4=.6a7994b6-fd97-4cc8-8f98-4a5855074a06@github.com>
 <2nHlMA_m35Al9nbcBILE63XcB63XuSWI_RbcUC96-As=.4fe30c48-52ab-4995-b0a1-f327009aa8a8@github.com>
Message-ID: <039lZ4RUKsmDUJAZEitlkbrvCE7p9w37KIc-F7Qr7jA=.f3e24088-bba3-448a-8720-649928de23f2@github.com>

On Thu, 5 May 2022 03:17:35 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 1363:
>> 
>>> 1361:       // Use the vector blend to implement the masked store. The biased elements are the original
>>> 1362:       // values in the memory.
>>> 1363:       Node* mem_val = gvn().transform(LoadVectorNode::make(0, control(), memory(addr), addr, addr_type, mem_num_elem, mem_elem_bt));
>> 
>> I'm sorry to say it, but I am pretty sure this is an invalid optimization.
>> See top-level comment for more details.
>
> Thanks for your comments! Yeah, this actually influences something due to the Java Memory Model rules which I missed to consider more. I will try the scatter ways instead. Thanks so much!

Yes, phantom store can write back stale unintended value and may create problem in multithreded applications since blending is done with an older loaded value.

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

PR: https://git.openjdk.java.net/jdk/pull/8544

From jbhateja at openjdk.java.net  Thu May  5 05:47:47 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 5 May 2022 05:47:47 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v2]
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <MCeN_ZJLMC5Ym1gSkXfGzz4PaSD9uN18tv67UGEtVYE=.1214b583-9d8f-4982-915a-088dc432bc3e@github.com>

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - 8284960: Correcting a typo.
 - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: AARCH64 backend changes.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Integration of JEP 426: Vector API (Fourth Incubator)

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

Changes: https://git.openjdk.java.net/jdk/pull/8425/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=01
  Stats: 37900 lines in 214 files changed: 16527 ins; 16923 del; 4450 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425

PR: https://git.openjdk.java.net/jdk/pull/8425

From john.r.rose at oracle.com  Thu May  5 06:16:07 2022
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 5 May 2022 06:16:07 +0000
Subject: RFR: 8284050: [vectorapi] Optimize masked store for
 non-predicated architectures [v2]
In-Reply-To: <4k-ZTE8Uax5vrH9GMAc2MJClnaIc4zB9vteafm24S44=.e1f50cc8-3020-4091-831f-e5fa2b623f7a@github.com>
References: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
 <B8DYwlRUNusrIQc-RcJ6OmPn0mYEOiytmgFf9q8j9Vc=.8930f40a-e383-4ac9-8d14-697147f22e02@github.com>
 <4k-ZTE8Uax5vrH9GMAc2MJClnaIc4zB9vteafm24S44=.e1f50cc8-3020-4091-831f-e5fa2b623f7a@github.com>
Message-ID: <EFCC9B16-A2AF-42BC-A0CB-43B3960F20E1@oracle.com>



> On May 4, 2022, at 8:29 PM, Xiaohong Gong <xgong at openjdk.java.net> wrote:
> 
> The offset check could save the `checkMaskFromIndexSize`  for cases that offset are in the valid array bounds, which also improves the performance. @rose00 , do you think this part of change is ok at least?

That part is ok, yes. I wish we could get the same effect with loop optimizations but I don?t know an easy way. The explicit check in the source code gives the JIT a crutch but I hope we can figure out a way in the future to integrate mask logic into range check elimination logic, making the crutches unnecessary. For now it?s fine. 

From itakiguchi at openjdk.java.net  Thu May  5 08:12:25 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Thu, 5 May 2022 08:12:25 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v4]
In-Reply-To: <tRSCLtwhcT3K3Cdy8VZC4qQGS33-Uss4jEUZNlfjeHw=.4a38432f-8fb3-4ad3-9cb4-906f2ceea673@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <1dZ6o94-xt1oOEevAAO3uYDQrjStchH0FfrHi88V1OE=.bbc63a8f-7959-46fa-ad9c-292c09e80ae5@github.com>
 <tRSCLtwhcT3K3Cdy8VZC4qQGS33-Uss4jEUZNlfjeHw=.4a38432f-8fb3-4ad3-9cb4-906f2ceea673@github.com>
Message-ID: <akwgpvANqHGDDCGK-76rJEvaIfBX2wQ42NaPyHPjq3k=.e6c1ebf3-6d5b-41db-9961-19d99e8d4677@github.com>

On Thu, 5 May 2022 01:31:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 73:
> 
>> 71:         @SuppressWarnings("removal")
>> 72:         String jnuEncoding = AccessController.doPrivileged((PrivilegedAction<String>) ()
>> 73:             -> System.getProperty("sun.jnu.encoding"));
> 
> No need to issue `doPrivileged()`, which is deprecated

Hello @naotoj .
If I just use `System.getProperty("sun.jnu.encoding")`, following testcases were failed.

java/lang/ProcessBuilder/SecurityManagerClinit.java 
java/lang/ProcessHandle/PermissionTest.java 

Please give me your suggestion again.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From xgong at openjdk.java.net  Thu May  5 08:41:11 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 08:41:11 GMT
Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated
 architectures [v2]
In-Reply-To: <B8DYwlRUNusrIQc-RcJ6OmPn0mYEOiytmgFf9q8j9Vc=.8930f40a-e383-4ac9-8d14-697147f22e02@github.com>
References: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
 <B8DYwlRUNusrIQc-RcJ6OmPn0mYEOiytmgFf9q8j9Vc=.8930f40a-e383-4ac9-8d14-697147f22e02@github.com>
Message-ID: <z-TwzG1XWP1p80w7TWSJaHQ14q-eM5v7qRaGpcZFVKA=.58f8ec3b-b132-4f91-8034-dbeaa5cc3977@github.com>

On Thu, 5 May 2022 02:09:39 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with:
>> 
>> 
>>  1) mem_v = load(addr)     ; non-masked load from the same memory
>>  2) v = blend(mem_v, v, m) ; blend with the src vector with the mask
>>  3) store(addr, v)         ; non-masked store into the memory
>> 
>> 
>> Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API.
>> 
>> Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`:
>> 
>> Benchmark                                  before    after   Units
>> StoreMaskedBenchmark.byteStoreArrayMask   221.733  11094.126 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  41.086   1034.408 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   73.820   1985.015 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     75.028   2027.557 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    40.929   1032.928 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask  135.794   5307.567 ops/ms
>> 
>> Similar performance gain can also be observed on ARM NEON system.
>> 
>> And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`:
>> 
>> Benchmark                                  before     after   Units
>> StoreMaskedBenchmark.byteStoreArrayMask   11185.956 21012.824 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  1480.644  3911.720 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   2738.352  7708.365 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     4191.904  9300.428 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    2025.031  4604.504 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask   8339.389 17817.128 ops/ms
>> 
>> Similar performance gain can also be observed on ARM SVE system.
>
> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8284050: [vectorapi] Optimize masked store for non-predicated architectures

> _Mailing list message from [John Rose](mailto:john.r.rose at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> 
> > On May 4, 2022, at 8:29 PM, Xiaohong Gong <xgong at openjdk.java.net> wrote:
> > The offset check could save the `checkMaskFromIndexSize`  for cases that offset are in the valid array bounds, which also improves the performance. @rose00 , do you think this part of change is ok at least?
> 
> That part is ok, yes. I wish we could get the same effect with loop optimizations but I don?t know an easy way. The explicit check in the source code gives the JIT a crutch but I hope we can figure out a way in the future to integrate mask logic into range check elimination logic, making the crutches unnecessary. For now it?s fine.

Thanks! So I will separate this part out and fix it in another PR first. For the store masked vectorization with scatter or other ideas, I'm not quite sure whether they can always benefit cross architectures and need more investigation. I prefer to close this PR now. Thanks for all your comments!

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

PR: https://git.openjdk.java.net/jdk/pull/8544

From xgong at openjdk.java.net  Thu May  5 08:41:12 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 08:41:12 GMT
Subject: Withdrawn: 8284050: [vectorapi] Optimize masked store for
 non-predicated architectures
In-Reply-To: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
References: <S3EYep_gaKzmHN3cY5lBLwePEJVCXqAcLVm9JuYFbF4=.2b5547f6-199c-4a97-b014-a0f2be6638a2@github.com>
Message-ID: <_XofoM1n91tFSRAE0q4CCkysHFK4Wha8a4IYaoj2xsU=.3df8d210-cf52-4bf0-81ba-a4cf3491ad20@github.com>

On Thu, 5 May 2022 02:00:04 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with:
> 
> 
>  1) mem_v = load(addr)     ; non-masked load from the same memory
>  2) v = blend(mem_v, v, m) ; blend with the src vector with the mask
>  3) store(addr, v)         ; non-masked store into the memory
> 
> 
> Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API.
> 
> Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`:
> 
> Benchmark                                  before    after   Units
> StoreMaskedBenchmark.byteStoreArrayMask   221.733  11094.126 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  41.086   1034.408 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   73.820   1985.015 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     75.028   2027.557 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    40.929   1032.928 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask  135.794   5307.567 ops/ms
> 
> Similar performance gain can also be observed on ARM NEON system.
> 
> And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`:
> 
> Benchmark                                  before     after   Units
> StoreMaskedBenchmark.byteStoreArrayMask   11185.956 21012.824 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  1480.644  3911.720 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   2738.352  7708.365 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     4191.904  9300.428 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    2025.031  4604.504 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask   8339.389 17817.128 ops/ms
> 
> Similar performance gain can also be observed on ARM SVE system.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8544

From xgong at openjdk.java.net  Thu May  5 08:56:07 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 08:56:07 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>

> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
> 
> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
> 
> 
>   @ForceInline
>   public static
>   ByteVector fromArray(VectorSpecies<Byte> species,
>                        byte[] a, int offset,
>                        VectorMask<Byte> m) {
>   ByteSpecies vsp = (ByteSpecies) species;
>       if (offset >= 0 && offset <= (a.length - species.length())) {
>           return vsp.dummyVector().fromArray0(a, offset, m);
>       }
> 
>       // FIXME: optimize
>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>       return vsp.vOp(m, i -> a[offset + i]);
>   }
> 
> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
> 
> Also adds the same vectorization support for masked:
>  - fromByteArray/fromByteBuffer
>  - fromBooleanArray
>  - fromCharArray
> 
> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
> 
> Benchmark                                          before   After  Units
> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
> 
> Similar performance gain can also be observed on 512-bit SVE system.

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

  Rename "use_predicate" to "needs_predicate"

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8035/files
  - new: https://git.openjdk.java.net/jdk/pull/8035/files/9b2d2f19..9c69206e

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

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8035.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Thu May  5 08:56:08 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 5 May 2022 08:56:08 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v2]
In-Reply-To: <CqeQUhahiO7s0utUXnwKFO0z96hNbENK6J8qgKeA9oo=.0f502361-d551-4e36-a0e5-10618bb75f9e@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <SELcvHEfuLHh6dK5GBDlSs22OKW_RxBlmtNKaF9kThs=.d5ff2b56-0e22-4640-92a5-beb21c901129@github.com>
 <Zs4vCQJvlQMoBVVbQ-EWeIad-aN48Gddsh-ft51_6PQ=.01b18a0c-b15e-4791-95be-895a413080f0@github.com>
 <CqeQUhahiO7s0utUXnwKFO0z96hNbENK6J8qgKeA9oo=.0f502361-d551-4e36-a0e5-10618bb75f9e@github.com>
Message-ID: <yYWHhrlPCH_ZQHA5Mmb9ctJs40qkPLAz7sfmjyibWRE=.ca73ad43-d169-44bc-99ef-086130fb892b@github.com>

On Thu, 5 May 2022 02:14:08 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 1232:
>> 
>>> 1230:   // out when current case uses the predicate feature.
>>> 1231:   if (!supports_predicate) {
>>> 1232:     bool use_predicate = false;
>> 
>> If we rename this to needs_predicate it will be easier to understand.
>
> Thanks for the comment! This local variable will be removed after adding the similar intrinsify for store masked. Please help to see the PR https://github.com/openjdk/jdk/pull/8544. Thanks so much!

Renamed to "needs_predicate". Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From sundar at openjdk.java.net  Thu May  5 09:08:39 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 5 May 2022 09:08:39 GMT
Subject: RFR: 8282060: RemoteRuntimeImageTest is not actually testing on JDK 8
Message-ID: <NCQoHDPwzGSZYhCkTZ5LOl7OeminHKGgoYOlBBJEong=.391d6329-bc99-441a-acd1-5cf1d4e68cb9@github.com>

This test requires jdk8 to be available while running jdk tests. But JDK8_HOME is defined to be BOOT_JDK and so version check fails in the test. The test vacuously passes just printing a message. There are already tests that exercise jrt-fs.jar on the same JDK being tested and so basic jrt-fs.jar is covered for same target JDK case.

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

Commit messages:
 - 8282060: RemoteRuntimeImageTest is not actually testing on JDK 8

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

PR: https://git.openjdk.java.net/jdk/pull/8547

From simonis at openjdk.java.net  Thu May  5 09:12:22 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 5 May 2022 09:12:22 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v2]
In-Reply-To: <hpt-Q0_errzRUETHJOzF6Ms8kQCNVLLm6Uqoegfy0Ps=.9f40508c-089d-46a3-8cc3-1e8a974f0c7c@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <u7SmxIfTCznpuW55CMpzxmA1snjfx_zTamEroCwIS1A=.e1c5fb16-b27e-464b-8395-9e580383c0e0@github.com>
 <Yvhoqqm8__c1-DHsMd8orphrRgWeX92WuXGxnPTU-M4=.56898485-2c3f-4155-a93b-c08c886e9b23@github.com>
 <5n-I0E5OO7uAHLo7fWdPqgAojcWpMMIB_AhGrxSKRVA=.a38c974d-eafd-4bbf-85ec-2eb457105b59@github.com>
 <hpt-Q0_errzRUETHJOzF6Ms8kQCNVLLm6Uqoegfy0Ps=.9f40508c-089d-46a3-8cc3-1e8a974f0c7c@github.com>
Message-ID: <Jd68D9yHvIfhbz7SaP5Yh3wMMPDSeZlD1WAb1vj0QBc=.e7346350-cbef-40b0-abfd-4614af59501f@github.com>

On Wed, 30 Mar 2022 10:26:56 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> Hello Volker, An additional thing that we might have to consider here is whether adding this javadoc change to `InflaterInputStream` is ever going to "show up" to end user applications. What I mean is, I think in many cases the end user applications won't even know they are dealing with an `InflaterInputStream`. For example, the following code:
>>> 
>>> ```
>>> ZipFile zf = ...
>>> ZipEntry ze = zf.getEntry("some-file");
>>> InputStream is = zf.getInputStream(ze);
>>> ```
>>> 
>>> As we see above, none of these APIs talk about `InflaterInputStream` (the return type of `ZipFile.getInpustream(...)` is an `InputStream`). So end users won't be able to view this spec change. Perhaps we should also add some note in the `ZipFile.getInpustream(....)` API to make a mention of this potential difference in behaviour of the returned stream?
>> 
>> You are right with your observation and I'll be happy to add a corresponding comment if @LanceAndersen and @AlanBateman agree. Please let me know what you think?
>
>> > Hello Volker, An additional thing that we might have to consider here is whether adding this javadoc change to `InflaterInputStream` is ever going to "show up" to end user applications. What I mean is, I think in many cases the end user applications won't even know they are dealing with an `InflaterInputStream`. For example, the following code:
>> > ```
>> > ZipFile zf = ...
>> > ZipEntry ze = zf.getEntry("some-file");
>> > InputStream is = zf.getInputStream(ze);
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > As we see above, none of these APIs talk about `InflaterInputStream` (the return type of `ZipFile.getInpustream(...)` is an `InputStream`). So end users won't be able to view this spec change. Perhaps we should also add some note in the `ZipFile.getInpustream(....)` API to make a mention of this potential difference in behaviour of the returned stream?
>> 
>> You are right with your observation and I'll be happy to add a corresponding comment if @LanceAndersen and @AlanBateman agree. Please let me know what you think?
> 
> Hi Volker,
> 
> I believe Jai raises a valid point given these javadocs probably have had limited updates if any since the API was originally added.    We should look at ZipInputStream and GZipInputStream as well if we decide to update the ZipFile::getInputStream(where we could borrow some wording from the ZipInputStream class description as a start to some word smithing).
> 
> As Roger points out we will need a release note for this change as well.

@LanceAndersen, @AlanBateman can you please comment on the [CSR](https://bugs.openjdk.java.net/browse/JDK-8283758) for this issue. We now circled back to the initial proposal in the  [CSR](https://bugs.openjdk.java.net/browse/JDK-8283758) but  @jddarcy would like to hear your opinion.

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

PR: https://git.openjdk.java.net/jdk/pull/7986

From alanb at openjdk.java.net  Thu May  5 09:35:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 09:35:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
 - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
 - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=11
  Stats: 99452 lines in 1130 files changed: 91184 ins; 3598 del; 4670 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu May  5 09:47:38 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 09:47:38 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11]
In-Reply-To: <Q3DstnYGNVgBXkn57bQirgdwlubtfPhnhkirhbjZMjk=.ad2e9a0f-b49c-47ad-b7c3-88037905f3ad@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <TGoQByO-TEVhk2tPwEEhXYSPBghWEV23Bqni4AKT1ME=.f94dc6e0-15e4-44ad-8e8e-3fcc57b63de2@github.com>
 <Q3DstnYGNVgBXkn57bQirgdwlubtfPhnhkirhbjZMjk=.ad2e9a0f-b49c-47ad-b7c3-88037905f3ad@github.com>
Message-ID: <gGcWBFyWAFSVEUgLsrurXb3OlGSwQT-jj0rOiQbcbUI=.406d3188-fa19-46a1-86cc-31d97c9812ce@github.com>

On Wed, 4 May 2022 16:02:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> So, does this PR pass current GHA checks? I see they are not enabled for this PR. It would be unfortunate for this large integration to break builds/tests for smaller PRs that would follow it.

I've enabled it on my fork and we'll see if it kicks in.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu May  5 09:55:13 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 09:55:13 GMT
Subject: RFR: 8282060: RemoteRuntimeImageTest is not actually testing on
 JDK 8
In-Reply-To: <NCQoHDPwzGSZYhCkTZ5LOl7OeminHKGgoYOlBBJEong=.391d6329-bc99-441a-acd1-5cf1d4e68cb9@github.com>
References: <NCQoHDPwzGSZYhCkTZ5LOl7OeminHKGgoYOlBBJEong=.391d6329-bc99-441a-acd1-5cf1d4e68cb9@github.com>
Message-ID: <HvG1nrZ2-qneH0NsYvzlrSkarYHljUDsiLAGl1CnyJc=.49e59530-3b05-4b05-abe3-a4cd0105b499@github.com>

On Thu, 5 May 2022 09:00:47 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> This test requires jdk8 to be available while running jdk tests. But JDK8_HOME is defined to be BOOT_JDK and so version check fails in the test. The test vacuously passes just printing a message. There are already tests that exercise jrt-fs.jar on the same JDK being tested and so basic jrt-fs.jar is covered for same target JDK case.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8547

From duke at openjdk.java.net  Thu May  5 10:18:45 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 5 May 2022 10:18:45 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
Message-ID: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>

Add a family of "safe" cast methods.

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

Commit messages:
 - 8279986: methods Math::asXExact for safely checked primitive casts
 - 8279986: methods Math::asXExact for safely checked primitive casts
 - 8279986: methods Math::asXExact for safely checked primitive casts

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

PR: https://git.openjdk.java.net/jdk/pull/8548

From duke at openjdk.java.net  Thu May  5 10:18:45 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 5 May 2022 10:18:45 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
In-Reply-To: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
Message-ID: <gN8eeIeHUW1wL69LHTUK6PUMQdAJNQzERBr76Ypg-xQ=.37f54937-3b7d-4468-b957-9b70c04c596d@github.com>

On Thu, 5 May 2022 10:11:05 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Add a family of "safe" cast methods.

For an in-depth rationale, please refer to the issue (Enhancement).
Note that the method names are, in fact, of the to*Exact rather than of the as*Exact form

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

PR: https://git.openjdk.java.net/jdk/pull/8548

From jpai at openjdk.java.net  Thu May  5 10:37:08 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 5 May 2022 10:37:08 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v4]
In-Reply-To: <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
Message-ID: <9pMv6ousT9vAgytcnUdNv0hnzCXvxCF5ywP9jkgzBvU=.f750ddd4-20dc-4769-a06e-f673d6453e69@github.com>

On Wed, 4 May 2022 19:16:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some assertions for entrySet.equals and keySet.equals

Hello Stuart, these changes look good to me.

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

Marked as reviewed by jpai (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8354

From jpai at openjdk.java.net  Thu May  5 10:37:09 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 5 May 2022 10:37:09 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v2]
In-Reply-To: <GNcNLDkJvhllvmuXeCG0efKRiYaa5YH-xJprqgtzNDA=.5a1a59e1-a822-4a87-a35e-75a5a9c6cfae@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <4XJX8EqCKg6NfIgEIyodh-cSuAIiCE2U3udBELzfHfU=.954deb03-ba07-4904-a1fd-9ee6173bc157@github.com>
 <xtdHeFzawIikwPXvBzWQzNTskLV0D1N8cM5eSUjYLkU=.95105955-b28c-46e7-a63d-e421a9e2f48e@github.com>
 <GNcNLDkJvhllvmuXeCG0efKRiYaa5YH-xJprqgtzNDA=.5a1a59e1-a822-4a87-a35e-75a5a9c6cfae@github.com>
Message-ID: <0tQxSqlZuw2FihTZEp7GPY6SNz5yMQUMy0EPXHvyLhA=.3e505fd9-9310-4a0e-ba70-378d4cf73ecc@github.com>

On Wed, 4 May 2022 15:02:43 GMT, liach <duke at openjdk.java.net> wrote:

>> test/jdk/java/util/IdentityHashMap/Basic.java line 500:
>> 
>>> 498:         Box newKey = new Box(k1a);
>>> 499:         Box newVal = new Box(v1a);
>>> 500:         Box r = map.computeIfAbsent(newKey, k -> { called[0] = true; return newVal; });
>> 
>> More of a curiosity than a review comment - I see that various places in this PR use a boolean array with one element instead of just a boolean type. Is that a personal coding preference or is there something more to it?
>
> This just serves as a modifiable boolean like an AtomicBoolean. Remember lambdas can only use final local var references (due to how they work), and it cannot access or modify the local variable in the caller method.

Thank you @liach and Stuart. I had overlooked the lambda aspect of this.

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From abimpoudis at openjdk.java.net  Thu May  5 12:09:18 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 5 May 2022 12:09:18 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <ARuPq5vlo0dKLhaeZUYa30wcFd7GDZp-twt8cu4B1Zg=.436547c2-b52f-4c68-89bf-468416a99a2a@github.com>

On Tue, 3 May 2022 12:07:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 783:

> 781:             }
> 782:             for (Entry<Symbol, List<JCDeconstructionPattern>> e : categorizedDeconstructionPatterns.entrySet()) {
> 783:                 if (coversDeconstructionStartingFromComponent(pos, targetType, e.getValue(), 0)) {

Here, the result of `e.getValue` is a reversed list of the observed patterns. 

For the switch below,


switch (r) {
            case R(A a, A b) -> 1;
            case R(A a, B b) -> 2;
            case R(B a, A b) -> 3;
            case R(B a, B b) -> 4;
}


The 0th element of that list is the `R(B a, B b)` pattern, the 1st the `R(B a, A b)`. I am 99% sure that this is not a problem but I am pointing it out regardless, in case there is any underlying danger to that.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From abimpoudis at openjdk.java.net  Thu May  5 12:09:18 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 5 May 2022 12:09:18 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
Message-ID: <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>

On Wed, 4 May 2022 10:51:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 824:
> 
>> 822:                 }
>> 823:                 for (Symbol currentType : nestedCovered) {
>> 824:                     if (types.isSubtype(types.erasure(currentType.type),
> 
> Not 100% what this test does

I think this is i) from the domination relation:

> A record pattern with type R and record component pattern list L dominates another record pattern with type S and record component pattern list M if (i) the erasure of S is a subtype of the erasure of R, and (ii) every pattern, if any, in L dominates the corresponding pattern in M.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mdoerr at openjdk.java.net  Thu May  5 12:19:19 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 5 May 2022 12:19:19 GMT
Subject: RFR: JDK-8285987: executing shell scripts without #! fails on
 Alpine linux
In-Reply-To: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
References: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
Message-ID: <K9XMH3Hqd1vNDspbzD9XZsMgusyahzB6lLKi32n5NZ4=.a1ad9974-ebe3-43bc-b1ed-9c6ecc1e677a@github.com>

On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 .
> Looks like this is a known issue on musl / Alpine, see also
> https://www.openwall.com/lists/musl/2018/03/09/2
> and
> https://github.com/scala-steward-org/scala-steward/issues/1374
> (we see it on Alpine 3.15).

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8535

From mcimadamore at openjdk.java.net  Thu May  5 12:20:17 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 May 2022 12:20:17 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
Message-ID: <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>

On Thu, 5 May 2022 12:06:38 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> I think this is i) from the domination relation:
> 
> > A record pattern with type R and record component pattern list L dominates another record pattern with type S and record component pattern list M if (i) the erasure of S is a subtype of the erasure of R, and (ii) every pattern, if any, in L dominates the corresponding pattern in M.

But this subtyping test seems to happen at the level of the component pattern list, not at the R/S level, right?

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From goetz at openjdk.java.net  Thu May  5 12:28:20 2022
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Thu, 5 May 2022 12:28:20 GMT
Subject: RFR: JDK-8285987: executing shell scripts without #! fails on
 Alpine linux
In-Reply-To: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
References: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
Message-ID: <npZRU0QsITyzUXl0ASYhxSKfLAz7M0Gb4RMe6Ns6drY=.8c995d87-43ac-4866-a3cc-346ceb16e57b@github.com>

On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 .
> Looks like this is a known issue on musl / Alpine, see also
> https://www.openwall.com/lists/musl/2018/03/09/2
> and
> https://github.com/scala-steward-org/scala-steward/issues/1374
> (we see it on Alpine 3.15).

Looks good

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

Marked as reviewed by goetz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8535

From abimpoudis at openjdk.java.net  Thu May  5 12:32:14 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 5 May 2022 12:32:14 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
 <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>
Message-ID: <2GavSjSE5nlrTyB3jqq-MfzgrPPk61-alJ5lr1NNXMw=.87eaf812-dffb-4d45-82e5-9af4dd1552ce@github.com>

On Thu, 5 May 2022 12:16:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I think this is i) from the domination relation:
>> 
>>> A record pattern with type R and record component pattern list L dominates another record pattern with type S and record component pattern list M if (i) the erasure of S is a subtype of the erasure of R, and (ii) every pattern, if any, in L dominates the corresponding pattern in M.
>
>> I think this is i) from the domination relation:
>> 
>> > A record pattern with type R and record component pattern list L dominates another record pattern with type S and record component pattern list M if (i) the erasure of S is a subtype of the erasure of R, and (ii) every pattern, if any, in L dominates the corresponding pattern in M.
> 
> But this subtyping test seems to happen at the level of the component pattern list, not at the R/S level, right?

You are right. It is the ii) which iteratively checks the component pattern list L.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From erikj at openjdk.java.net  Thu May  5 12:48:17 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 5 May 2022 12:48:17 GMT
Subject: RFR: 8282060: RemoteRuntimeImageTest is not actually testing on
 JDK 8
In-Reply-To: <NCQoHDPwzGSZYhCkTZ5LOl7OeminHKGgoYOlBBJEong=.391d6329-bc99-441a-acd1-5cf1d4e68cb9@github.com>
References: <NCQoHDPwzGSZYhCkTZ5LOl7OeminHKGgoYOlBBJEong=.391d6329-bc99-441a-acd1-5cf1d4e68cb9@github.com>
Message-ID: <deFpuOf7q9aEcKv4hFpVArTr_BPqwAMmbJvty3xq2no=.435146bf-ac87-451f-ae59-abf57531debc@github.com>

On Thu, 5 May 2022 09:00:47 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> This test requires jdk8 to be available while running jdk tests. But JDK8_HOME is defined to be BOOT_JDK and so version check fails in the test. The test vacuously passes just printing a message. There are already tests that exercise jrt-fs.jar on the same JDK being tested and so basic jrt-fs.jar is covered for same target JDK case.

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8547

From mbaesken at openjdk.java.net  Thu May  5 12:49:19 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 5 May 2022 12:49:19 GMT
Subject: RFR: JDK-8285987: executing shell scripts without #! fails on
 Alpine linux
In-Reply-To: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
References: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
Message-ID: <uKWNbU3VqiUsXKTxqU3JPwYNCTJYHxPJ3S5GbcNQxKw=.3d222c0d-28cd-405b-aa36-9653b69a410f@github.com>

On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 .
> Looks like this is a known issue on musl / Alpine, see also
> https://www.openwall.com/lists/musl/2018/03/09/2
> and
> https://github.com/scala-steward-org/scala-steward/issues/1374
> (we see it on Alpine 3.15).

Hi Martin and Goetz, thanks for the reviews.

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

PR: https://git.openjdk.java.net/jdk/pull/8535

From mbaesken at openjdk.java.net  Thu May  5 12:49:19 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 5 May 2022 12:49:19 GMT
Subject: Integrated: JDK-8285987: executing shell scripts without #! fails on
 Alpine linux
In-Reply-To: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
References: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
Message-ID: <vrVCRM6rfQI_JFXvueWMWJQyUIVd8arZvdNzp_H_paw=.cedf6907-967b-405d-85b4-befa0d3c6e84@github.com>

On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 .
> Looks like this is a known issue on musl / Alpine, see also
> https://www.openwall.com/lists/musl/2018/03/09/2
> and
> https://github.com/scala-steward-org/scala-steward/issues/1374
> (we see it on Alpine 3.15).

This pull request has now been integrated.

Changeset: 9d2f591e
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9d2f591e6a15dc155a8cc3b18a54456d5f9a3aa7
Stats:     35 lines in 3 files changed: 17 ins; 0 del; 18 mod

8285987: executing shell scripts without #! fails on Alpine linux

Reviewed-by: mdoerr, goetz

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

PR: https://git.openjdk.java.net/jdk/pull/8535

From aturbanov at openjdk.java.net  Thu May  5 13:23:12 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 5 May 2022 13:23:12 GMT
Subject: Integrated: 8285947: Avoid redundant HashMap.containsKey calls in
 ZoneName
In-Reply-To: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
References: <-289ZRaINDGkukS0MxRVkr7LUWmuphh83C1qoYLlBo0=.9bfc0aac-c491-46af-b726-f9788789ef23@github.com>
Message-ID: <hU-nfTU94F9BQSYcsdgIS2gqHaDNP7Zi4XfIyqPWuOQ=.21f180aa-b455-4219-9de3-119edcc4086d@github.com>

On Fri, 29 Apr 2022 06:31:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Map.containsKey` call is sometimes unnecessary, when it's known that Map doesn't contain `null` values.
> Instead we can just use Map.get and compare result with `null`.
> I found one of such place, where Map.containsKey calls could be eliminated - `java.time.format.ZoneName`.
> it gives a bit of performance for `toZid`.
> 
> 
> Benchmark                             Mode  Cnt   Score   Error  Units
> ZoneNamesBench.useExistingCountry     avgt    5  10,738 ? 0,065  ns/op
> ZoneNamesBench.useExistingCountryOld  avgt    5  13,679 ? 0,089  ns/op
> 
> 
> <details>
> <summary>Benchmark</summary>
> 
> 
> @BenchmarkMode(value = Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Benchmark)
> public class ZoneNamesBench {
> 
>     @Benchmark
>     public String useExistingCountry() {
>         return ZoneName.toZid("Africa/Tunis", Locale.ITALY);
>     }
> 
>     @Benchmark
>     public String useExistingCountryOld() {
>         return ZoneName.toZidOld("Africa/Tunis", Locale.ITALY);
>     }
> }
> 
> 
> 
>     public static String toZid(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null) {
>             String alias = aliases.get(zid);
>             if (alias != null) {
>                 zid = alias;
>                 mzone = zidToMzone.get(zid);
>             }
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map == null || ((zid = map.get(locale.getCountry())) == null)) {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZid(zid);
>     }
> 
>     public static String toZid(String zid) {
>         return aliases.getOrDefault(zid, zid);
>     }
> 
>     public static String toZidOld(String zid, Locale locale) {
>         String mzone = zidToMzone.get(zid);
>         if (mzone == null && aliases.containsKey(zid)) {
>             zid = aliases.get(zid);
>             mzone = zidToMzone.get(zid);
>         }
>         if (mzone != null) {
>             Map<String, String> map = mzoneToZidL.get(mzone);
>             if (map != null && map.containsKey(locale.getCountry())) {
>                 zid = map.get(locale.getCountry());
>             } else {
>                 zid = mzoneToZid.get(mzone);
>             }
>         }
>         return toZidOld(zid);
>     }
> 
>     public static String toZidOld(String zid) {
>         if (aliases.containsKey(zid)) {
>             return aliases.get(zid);
>         }
>         return zid;
>     }
> 
> </details>

This pull request has now been integrated.

Changeset: dce860aa
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dce860aa8a6b11501e82ace4ff016ee49d8e1fa4
Stats:     14 lines in 1 file changed: 3 ins; 5 del; 6 mod

8285947: Avoid redundant HashMap.containsKey calls in ZoneName

Reviewed-by: scolebourne, naoto, rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/8463

From sundar at openjdk.java.net  Thu May  5 13:26:31 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 5 May 2022 13:26:31 GMT
Subject: Integrated: 8282060: RemoteRuntimeImageTest is not actually testing on
 JDK 8
In-Reply-To: <NCQoHDPwzGSZYhCkTZ5LOl7OeminHKGgoYOlBBJEong=.391d6329-bc99-441a-acd1-5cf1d4e68cb9@github.com>
References: <NCQoHDPwzGSZYhCkTZ5LOl7OeminHKGgoYOlBBJEong=.391d6329-bc99-441a-acd1-5cf1d4e68cb9@github.com>
Message-ID: <e164Tm3vDUbJfTOMpfwxxrhSa38AsgM8Mpe-E6Jevq0=.43c4b2ce-17e2-48ac-8584-96825b2380bb@github.com>

On Thu, 5 May 2022 09:00:47 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> This test requires jdk8 to be available while running jdk tests. But JDK8_HOME is defined to be BOOT_JDK and so version check fails in the test. The test vacuously passes just printing a message. There are already tests that exercise jrt-fs.jar on the same JDK being tested and so basic jrt-fs.jar is covered for same target JDK case.

This pull request has now been integrated.

Changeset: ede06c3c
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ede06c3c5f74c64dac3889d35b02541897ba4d94
Stats:     202 lines in 3 files changed: 0 ins; 202 del; 0 mod

8282060: RemoteRuntimeImageTest is not actually testing on JDK 8

Reviewed-by: alanb, erikj

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

PR: https://git.openjdk.java.net/jdk/pull/8547

From duke at openjdk.java.net  Thu May  5 13:35:16 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 5 May 2022 13:35:16 GMT
Subject: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java
 fails with expected [true] but found [false]
In-Reply-To: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
References: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
Message-ID: <GUB0z6109e8auFW0TxZ6iC51tCv-QK2wkfmkZ54SQUs=.b0b98a24-cf0a-44b0-8e2d-72d5ee69f62c@github.com>

On Tue, 19 Apr 2022 08:40:51 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review these small changes to address intermittent failures, as of JDK-8274517.
> 
> - Usage of jdk.test.lib.RandomFactory for reproducible random generation.
> - Slightly less restrictive assertion about badParallelStreamError on L94 (former L88).
> - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18.
> 
> While these changes do not necessarily guarantee absence of intermittent failures, the usage of jdk.test.lib.RandomFactory should at least help to pin down specific double sequences that do not pass the test.
> 
> There is still an inherent variability due to the use of parallel streams, though. As double addition is not perfectly associative, even a fully known sequence of doubles may lead to slightly different results with parallelization.

Anybody interested in reviewing?

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

PR: https://git.openjdk.java.net/jdk/pull/8290

From alanb at openjdk.java.net  Thu May  5 13:40:25 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 13:40:25 GMT
Subject: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java
 fails with expected [true] but found [false]
In-Reply-To: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
References: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
Message-ID: <vEgqeauBobUeZnDueIrMivXXeNevg9lXtgMqHPOQ5nI=.2949e8a6-de27-409b-8d51-ce802b0246e2@github.com>

On Tue, 19 Apr 2022 08:40:51 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review these small changes to address intermittent failures, as of JDK-8274517.
> 
> - Usage of jdk.test.lib.RandomFactory for reproducible random generation.
> - Slightly less restrictive assertion about badParallelStreamError on L94 (former L88).
> - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18.
> 
> While these changes do not necessarily guarantee absence of intermittent failures, the usage of jdk.test.lib.RandomFactory should at least help to pin down specific double sequences that do not pass the test.
> 
> There is still an inherent variability due to the use of parallel streams, though. As double addition is not perfectly associative, even a fully known sequence of doubles may lead to slightly different results with parallelization.

.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8290

From alanb at openjdk.java.net  Thu May  5 13:47:19 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 13:47:19 GMT
Subject: RFR: JDK-8285987: executing shell scripts without #! fails on
 Alpine linux
In-Reply-To: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
References: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
Message-ID: <nciY3Wr-q5QMV38ZAvBFOTvW6HrndI7ihGBv3NEceUU=.59a72de7-f8a0-4ec1-9f81-5d05f1932919@github.com>

On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 .
> Looks like this is a known issue on musl / Alpine, see also
> https://www.openwall.com/lists/musl/2018/03/09/2
> and
> https://github.com/scala-steward-org/scala-steward/issues/1374
> (we see it on Alpine 3.15).

test/lib/jdk/test/lib/Platform.java line 192:

> 190:     }
> 191: 
> 192:     public static boolean isMusl() {

I think this will need test/lib/TestMutuallyExclusivePlatformPredicates.java to be updated too.

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

PR: https://git.openjdk.java.net/jdk/pull/8535

From duke at openjdk.java.net  Thu May  5 13:59:31 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Thu, 5 May 2022 13:59:31 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v4]
In-Reply-To: <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
Message-ID: <E_9MdeHAYk0EnjCXdcsQT72XEhW_0ZsgH7LHqx1Y3Ww=.c8843575-2e9b-46ca-8e2f-ce1ee157dffd@github.com>

On Wed, 4 May 2022 19:16:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some assertions for entrySet.equals and keySet.equals

As?I?said in?[GH?6532]:
> There?should probably?be something?like [test/jdk/java/util/Collections/Wrappers.java] to?check?that `IdentityHashMap` overrides?all `default`?methods from?`java.util.Map` (with?`remove(K,?V)` and?`replace(K,?V,?V)` depending on?[GH?8259]).

[GH?6532]: https://github.com/openjdk/jdk/pull/6532#issuecomment-1104709021
[GH?8259]: https://github.com/openjdk/jdk/pull/8259
[test/jdk/java/util/Collections/Wrappers.java]: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/Collections/Wrappers.java

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From mbaesken at openjdk.java.net  Thu May  5 14:19:15 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 5 May 2022 14:19:15 GMT
Subject: RFR: JDK-8285987: executing shell scripts without #! fails on
 Alpine linux
In-Reply-To: <nciY3Wr-q5QMV38ZAvBFOTvW6HrndI7ihGBv3NEceUU=.59a72de7-f8a0-4ec1-9f81-5d05f1932919@github.com>
References: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
 <nciY3Wr-q5QMV38ZAvBFOTvW6HrndI7ihGBv3NEceUU=.59a72de7-f8a0-4ec1-9f81-5d05f1932919@github.com>
Message-ID: <u6WX_sKkKTKhtPngktfSMVT58XFERSdnEKkxzCdVREA=.df749c73-e784-4a5f-aa44-842d069ebea7@github.com>

On Thu, 5 May 2022 13:43:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 .
>> Looks like this is a known issue on musl / Alpine, see also
>> https://www.openwall.com/lists/musl/2018/03/09/2
>> and
>> https://github.com/scala-steward-org/scala-steward/issues/1374
>> (we see it on Alpine 3.15).
>
> test/lib/jdk/test/lib/Platform.java line 192:
> 
>> 190:     }
>> 191: 
>> 192:     public static boolean isMusl() {
> 
> I think this will need test/lib/TestMutuallyExclusivePlatformPredicates.java to be updated too.

Hi Alan, thanks for the advice;  do you think we can put it into the IGNORED group ?
https://github.com/openjdk/jdk/blob/master/test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java#L53

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

PR: https://git.openjdk.java.net/jdk/pull/8535

From duke at openjdk.java.net  Thu May  5 14:23:16 2022
From: duke at openjdk.java.net (Michael Hixson)
Date: Thu, 5 May 2022 14:23:16 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
In-Reply-To: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
Message-ID: <RndIi0WtfqcOUv7PaU1aVVYgXtCDU1tgrqojTULXg0g=.11d9de49-105d-4202-820e-e69578407159@github.com>

On Thu, 5 May 2022 10:11:05 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Add a family of "safe" cast methods.

This PR also solves [JDK-8154433](https://bugs.openjdk.java.net/browse/JDK-8154433), though you went the other way on -0.0.

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

PR: https://git.openjdk.java.net/jdk/pull/8548

From duke at openjdk.java.net  Thu May  5 14:36:20 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 5 May 2022 14:36:20 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
In-Reply-To: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
Message-ID: <5dOxIzoYTT94QD66v6miZ8vHrlh-Yr7uMMarA4S7B_I=.5a90b95f-d63a-403f-aae6-f82b5ed7e505@github.com>

On Thu, 5 May 2022 10:11:05 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Add a family of "safe" cast methods.

The JLS specifies that the cast (officially, "narrowing primitive conversion") (long)-0.0 returns 0L.
As these methods are meant to be safer casts, I think we should follow the JLS as closely as possible.

Besides, throwing on -0.0 would make the implementation slightly more convoluted. We want C2 to emit efficient inlineable code.

So, what is the use case or the rationale for throwing on -0.0?

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

PR: https://git.openjdk.java.net/jdk/pull/8548

From rriggs at openjdk.java.net  Thu May  5 14:42:41 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 14:42:41 GMT
Subject: RFR: 8286195: ProblemList
 test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java
Message-ID: <h1VdlGezbgwQoaU2utRQsG2DvDLhu1N4VDzfTfWuXoQ=.3361ee60-ab6c-4a61-9d74-dbe54ec3eff3@github.com>

Add a failing test library test to the ProblemList.

test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

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

Commit messages:
 - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

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

PR: https://git.openjdk.java.net/jdk/pull/8552

From dcubed at openjdk.java.net  Thu May  5 14:48:28 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 5 May 2022 14:48:28 GMT
Subject: RFR: 8286195: ProblemList
 test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java
In-Reply-To: <h1VdlGezbgwQoaU2utRQsG2DvDLhu1N4VDzfTfWuXoQ=.3361ee60-ab6c-4a61-9d74-dbe54ec3eff3@github.com>
References: <h1VdlGezbgwQoaU2utRQsG2DvDLhu1N4VDzfTfWuXoQ=.3361ee60-ab6c-4a61-9d74-dbe54ec3eff3@github.com>
Message-ID: <ElyNnoAmfzS0zDeGSI5D8ZmF6UysQ55Yv22DXfCs4Ew=.1ceb99b6-d25b-462f-a914-2503d579ff48@github.com>

On Thu, 5 May 2022 14:33:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add a failing test library test to the ProblemList.
> 
> test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8552

From lancea at openjdk.java.net  Thu May  5 14:48:28 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 5 May 2022 14:48:28 GMT
Subject: RFR: 8286195: ProblemList
 test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java
In-Reply-To: <h1VdlGezbgwQoaU2utRQsG2DvDLhu1N4VDzfTfWuXoQ=.3361ee60-ab6c-4a61-9d74-dbe54ec3eff3@github.com>
References: <h1VdlGezbgwQoaU2utRQsG2DvDLhu1N4VDzfTfWuXoQ=.3361ee60-ab6c-4a61-9d74-dbe54ec3eff3@github.com>
Message-ID: <KP8lGXC4Ro5RQMgwUj2l3fNt6DeHVFFyy-SnGZqkYlU=.1e178533-67b9-4e8a-bf62-e978b28bfeb1@github.com>

On Thu, 5 May 2022 14:33:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add a failing test library test to the ProblemList.
> 
> test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8552

From rriggs at openjdk.java.net  Thu May  5 14:48:30 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 14:48:30 GMT
Subject: Integrated: 8286195: ProblemList
 test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java
In-Reply-To: <h1VdlGezbgwQoaU2utRQsG2DvDLhu1N4VDzfTfWuXoQ=.3361ee60-ab6c-4a61-9d74-dbe54ec3eff3@github.com>
References: <h1VdlGezbgwQoaU2utRQsG2DvDLhu1N4VDzfTfWuXoQ=.3361ee60-ab6c-4a61-9d74-dbe54ec3eff3@github.com>
Message-ID: <zJHyxnlUMH_HvYVrkTRxOTOui4nsYksCSb6Dx4itMrM=.80f60185-0537-425e-8075-3490ce9cc008@github.com>

On Thu, 5 May 2022 14:33:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add a failing test library test to the ProblemList.
> 
> test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

This pull request has now been integrated.

Changeset: 7022543f
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7022543fcfa04c628ef962749ed96c8f986dc822
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8286195: ProblemList  test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

Reviewed-by: dcubed, lancea

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

PR: https://git.openjdk.java.net/jdk/pull/8552

From rriggs at openjdk.java.net  Thu May  5 14:49:28 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 14:49:28 GMT
Subject: RFR: JDK-8285987: executing shell scripts without #! fails on
 Alpine linux
In-Reply-To: <u6WX_sKkKTKhtPngktfSMVT58XFERSdnEKkxzCdVREA=.df749c73-e784-4a5f-aa44-842d069ebea7@github.com>
References: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
 <nciY3Wr-q5QMV38ZAvBFOTvW6HrndI7ihGBv3NEceUU=.59a72de7-f8a0-4ec1-9f81-5d05f1932919@github.com>
 <u6WX_sKkKTKhtPngktfSMVT58XFERSdnEKkxzCdVREA=.df749c73-e784-4a5f-aa44-842d069ebea7@github.com>
Message-ID: <MiABAdF_hKL8se8e0TmkH4dzFERluo-YDKv2TwNvN2c=.9f3e352b-61d7-4e2f-8f80-610a7842193c@github.com>

On Thu, 5 May 2022 14:15:30 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/lib/jdk/test/lib/Platform.java line 192:
>> 
>>> 190:     }
>>> 191: 
>>> 192:     public static boolean isMusl() {
>> 
>> I think this will need test/lib/TestMutuallyExclusivePlatformPredicates.java to be updated too.
>
> Hi Alan, thanks for the advice;  do you think we can put it into the IGNORED group ?
> https://github.com/openjdk/jdk/blob/master/test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java#L53

Its now on the ProblemList and Created Issue:
 [JDK-8286191](https://bugs.openjdk.java.net/browse/JDK-8286191) Test library test failure in TestMutuallyExclusivePlatformPredicates.java

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

PR: https://git.openjdk.java.net/jdk/pull/8535

From duke at openjdk.java.net  Thu May  5 15:11:17 2022
From: duke at openjdk.java.net (Michael Hixson)
Date: Thu, 5 May 2022 15:11:17 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
In-Reply-To: <5dOxIzoYTT94QD66v6miZ8vHrlh-Yr7uMMarA4S7B_I=.5a90b95f-d63a-403f-aae6-f82b5ed7e505@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <5dOxIzoYTT94QD66v6miZ8vHrlh-Yr7uMMarA4S7B_I=.5a90b95f-d63a-403f-aae6-f82b5ed7e505@github.com>
Message-ID: <VDjPC0Jr99uBOI4M0pcjG9itXXM6K54sTlhHKez3v5s=.d794ba55-fe49-442c-9b87-fa5d8baad784@github.com>

On Thu, 5 May 2022 14:32:36 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> So, what is the use case or the rationale for throwing on -0.0?

Rationale: It loses information.  It truncates the sign, so the value can't be round-tripped.  I think it would be the only lossy transformation permitted by the `to*Exact` methods?

Use case: None.  I haven't worked on a program where -0.0 -> OL -> +0.0 would have caused me a problem.

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

PR: https://git.openjdk.java.net/jdk/pull/8548

From rriggs at openjdk.java.net  Thu May  5 15:12:19 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 15:12:19 GMT
Subject: RFR: JDK-8285987: executing shell scripts without #! fails on
 Alpine linux
In-Reply-To: <MiABAdF_hKL8se8e0TmkH4dzFERluo-YDKv2TwNvN2c=.9f3e352b-61d7-4e2f-8f80-610a7842193c@github.com>
References: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
 <nciY3Wr-q5QMV38ZAvBFOTvW6HrndI7ihGBv3NEceUU=.59a72de7-f8a0-4ec1-9f81-5d05f1932919@github.com>
 <u6WX_sKkKTKhtPngktfSMVT58XFERSdnEKkxzCdVREA=.df749c73-e784-4a5f-aa44-842d069ebea7@github.com>
 <MiABAdF_hKL8se8e0TmkH4dzFERluo-YDKv2TwNvN2c=.9f3e352b-61d7-4e2f-8f80-610a7842193c@github.com>
Message-ID: <mZ9vjzQiv1t0Wg5PZ3mYKSXi5GR9AVApv2emPSUfec0=.651dac10-884f-4d82-a0f7-8ee438d5ef98@github.com>

On Thu, 5 May 2022 14:47:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi Alan, thanks for the advice;  do you think we can put it into the IGNORED group ?
>> https://github.com/openjdk/jdk/blob/master/test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java#L53
>
> Its now on the ProblemList and Created Issue:
>  [JDK-8286191](https://bugs.openjdk.java.net/browse/JDK-8286191) Test library test failure in TestMutuallyExclusivePlatformPredicates.java

This PR also caused a test failure in ExternalEditorTest because there is no defined value for "vm.musl" used in  @\requires.
What test were run before integration?

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

PR: https://git.openjdk.java.net/jdk/pull/8535

From duke at openjdk.java.net  Thu May  5 15:18:10 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 5 May 2022 15:18:10 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
In-Reply-To: <VDjPC0Jr99uBOI4M0pcjG9itXXM6K54sTlhHKez3v5s=.d794ba55-fe49-442c-9b87-fa5d8baad784@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <5dOxIzoYTT94QD66v6miZ8vHrlh-Yr7uMMarA4S7B_I=.5a90b95f-d63a-403f-aae6-f82b5ed7e505@github.com>
 <VDjPC0Jr99uBOI4M0pcjG9itXXM6K54sTlhHKez3v5s=.d794ba55-fe49-442c-9b87-fa5d8baad784@github.com>
Message-ID: <7zjW0BBAUngdl-22vr0tW2K4SseyBz1-DoqXF26KkvE=.6ba747cf-587a-403b-893f-f4b72741e1fd@github.com>

On Thu, 5 May 2022 15:07:32 GMT, Michael Hixson <duke at openjdk.java.net> wrote:

> Rationale: It loses information. It truncates the sign, so the value can't be round-tripped. I think it would be the only lossy transformation permitted by the to*Exact methods?

Right.

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

PR: https://git.openjdk.java.net/jdk/pull/8548

From mdoerr at openjdk.java.net  Thu May  5 15:28:28 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 5 May 2022 15:28:28 GMT
Subject: RFR: JDK-8285987: executing shell scripts without #! fails on
 Alpine linux
In-Reply-To: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
References: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
Message-ID: <1sjCy0VTLNkGW44pGTZDld1cq-5tFNH0i-_cLjPbX3Y=.5b3b41a6-5534-4a1a-814e-0d9eb5557282@github.com>

On Wed, 4 May 2022 12:04:47 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> A couple a tests like java/lang/ProcessBuilder/Basic.java#id0.Basic_id0 and jdk/jshell/ExternalEditorTest.java.ExternalEditorTest try to start small shell scripts without #! at the first line of the script. This fails with error=8, Exec format error when running on Alpine 3.15 .
> Looks like this is a known issue on musl / Alpine, see also
> https://www.openwall.com/lists/musl/2018/03/09/2
> and
> https://github.com/scala-steward-org/scala-steward/issues/1374
> (we see it on Alpine 3.15).

Strange. The pre-submit tests are all green.

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

PR: https://git.openjdk.java.net/jdk/pull/8535

From mbaesken at openjdk.java.net  Thu May  5 15:34:19 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 5 May 2022 15:34:19 GMT
Subject: RFR: JDK-8285987: executing shell scripts without #! fails on
 Alpine linux
In-Reply-To: <1sjCy0VTLNkGW44pGTZDld1cq-5tFNH0i-_cLjPbX3Y=.5b3b41a6-5534-4a1a-814e-0d9eb5557282@github.com>
References: <kUCQSqVgwzs_H2PO5DKeI7gNgocWgQwGZ04bE1LDRhY=.9979bd1f-c8e8-44f9-afad-2113e9adfacd@github.com>
 <1sjCy0VTLNkGW44pGTZDld1cq-5tFNH0i-_cLjPbX3Y=.5b3b41a6-5534-4a1a-814e-0d9eb5557282@github.com>
Message-ID: <Hnzb6RqGNt1LWmjisGrCID14b1XnH2k4RKWwtwvg-1o=.707fa685-e83a-4621-8122-20764bc4cfdd@github.com>

On Thu, 5 May 2022 15:24:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Strange. The pre-submit tests are all green.

Yes sorry  those seem not to cover these 2 findings.  And I think I locally run by mistake only the jdk test  instead of the jdk + langtools tests with my script , this will of course not show the langtools issue.
The green langtools/tier1 from presubmit might not include the ExternalEditorTest .

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

PR: https://git.openjdk.java.net/jdk/pull/8535

From rriggs at openjdk.java.net  Thu May  5 15:38:40 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 15:38:40 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
Message-ID: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>

Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

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

Commit messages:
 - 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
 - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From mbaesken at openjdk.java.net  Thu May  5 15:44:55 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 5 May 2022 15:44:55 GMT
Subject: RFR: JDK-8286191: misc tests fail due to JDK-8286191
Message-ID: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>

The isMusl method had to be handled in test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
Additionally, the vm.musl predicate seem not to be available in the langtools tests.

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

Commit messages:
 - remove from ProblemList
 - Merge remote-tracking branch 'origin/master' into JDK-8286191
 - JDK-8286191

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

PR: https://git.openjdk.java.net/jdk/pull/8556

From naoto at openjdk.java.net  Thu May  5 15:45:19 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 May 2022 15:45:19 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v4]
In-Reply-To: <akwgpvANqHGDDCGK-76rJEvaIfBX2wQ42NaPyHPjq3k=.e6c1ebf3-6d5b-41db-9961-19d99e8d4677@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <1dZ6o94-xt1oOEevAAO3uYDQrjStchH0FfrHi88V1OE=.bbc63a8f-7959-46fa-ad9c-292c09e80ae5@github.com>
 <tRSCLtwhcT3K3Cdy8VZC4qQGS33-Uss4jEUZNlfjeHw=.4a38432f-8fb3-4ad3-9cb4-906f2ceea673@github.com>
 <akwgpvANqHGDDCGK-76rJEvaIfBX2wQ42NaPyHPjq3k=.e6c1ebf3-6d5b-41db-9961-19d99e8d4677@github.com>
Message-ID: <jXmjmkVnLhV6WYxtzFPtK6fCemJvucY_ztds-qzL9-Q=.da298ef3-958b-45ae-9acd-08ff733a5b5a@github.com>

On Thu, 5 May 2022 08:08:29 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 73:
>> 
>>> 71:         @SuppressWarnings("removal")
>>> 72:         String jnuEncoding = AccessController.doPrivileged((PrivilegedAction<String>) ()
>>> 73:             -> System.getProperty("sun.jnu.encoding"));
>> 
>> No need to issue `doPrivileged()`, which is deprecated
>
> Hello @naotoj .
> If I just use `System.getProperty("sun.jnu.encoding")`, following testcases were failed.
> 
> java/lang/ProcessBuilder/SecurityManagerClinit.java 
> java/lang/ProcessHandle/PermissionTest.java 
> 
> Please give me your suggestion again.

Ah, OK. Never mind.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From mcimadamore at openjdk.java.net  Thu May  5 15:48:37 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 May 2022 15:48:37 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <UCFbYTr1ZOafb18sLjmi7h1X0vdur721OLDSvrba3Lw=.64954b7b-38f4-4b9e-8750-e90e6847edb3@github.com>

On Tue, 3 May 2022 12:07:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

I've added some renaming suggestions for the code in Flow, after some discussions with @biboudis.
More generally, that code should contain comments, with example of what it's trying to do - e.g. how it's partitioning the set of patterns, etc.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 64:

> 62:     public enum Feature {
> 63:         SWITCH_PATTERN_MATCHING,
> 64:         DECONSTRUCTION_PATTERNS,

The spec and JEP talks about record patterns - I think we should follow the correct name here

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 751:

> 749:                                            Iterable<? extends JCCaseLabel> labels) {
> 750:             Set<Symbol> constants = new HashSet<>();
> 751:             Map<Symbol, List<JCDeconstructionPattern>> categorizedDeconstructionPatterns = new HashMap<>();

maybe rename to `deconstructionPatternsBySymbol` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 790:

> 788:         }
> 789: 
> 790:         private boolean coversDeconstructionStartingFromComponent(DiagnosticPosition pos,

maybe rename as `coverDeconstructionFromComponent`/`coverDeconstructionAt`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 792:

> 790:         private boolean coversDeconstructionStartingFromComponent(DiagnosticPosition pos,
> 791:                                                                   Type targetType,
> 792:                                                                   List<JCDeconstructionPattern> patterns,

patterns -> "deconstructionPatterns"

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 800:

> 798:             }
> 799: 
> 800:             Type parameterizedComponentType = types.memberType(targetType, components.get(component));

maybe `instantiatedComponentType`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 802:

> 800:             Type parameterizedComponentType = types.memberType(targetType, components.get(component));
> 801:             List<JCPattern> nestedComponentPatterns = patterns.map(d -> d.nested.get(component));
> 802:             Set<Symbol> nestedCovered = coveredSymbols(pos, parameterizedComponentType,

maybe `coveredComponents`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 807:

> 805:             Set<Symbol> covered = new HashSet<>();
> 806: 
> 807:             for (JCDeconstructionPattern subTypeCandidate : patterns) {

`subTypeCandidate` -> `deconstructionPattern`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 809:

> 807:             for (JCDeconstructionPattern subTypeCandidate : patterns) {
> 808:                 JCPattern nestedPattern = subTypeCandidate.nested.get(component);
> 809:                 Symbol currentPatternType;

`currentPatternType` -> `componentPatternType`

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 823:

> 821:                     }
> 822:                 }
> 823:                 for (Symbol currentType : nestedCovered) {

`currentType` -> `coveredComponent`

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 246:

> 244:         PARENTHESIZEDPATTERN,
> 245: 
> 246:         DECONSTRUCTIONPATTERN,

might want to rename to RECORDPATTERN (but this is impl dependent, so less important to fix)

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 2373:

> 2371:     }
> 2372: 
> 2373:     public static class JCDeconstructionPattern extends JCPattern

JCRecordPattern (although this is impl-only, so less important to fix)

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mcimadamore at openjdk.java.net  Thu May  5 15:48:38 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 May 2022 15:48:38 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <2GavSjSE5nlrTyB3jqq-MfzgrPPk61-alJ5lr1NNXMw=.87eaf812-dffb-4d45-82e5-9af4dd1552ce@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
 <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>
 <2GavSjSE5nlrTyB3jqq-MfzgrPPk61-alJ5lr1NNXMw=.87eaf812-dffb-4d45-82e5-9af4dd1552ce@github.com>
Message-ID: <ff8zs0KPz1lnUAXZnOLmgOV29nrMku68gCzcXx22cfk=.e3013590-1330-45f9-9c8e-d39a1784aeda@github.com>

On Thu, 5 May 2022 12:28:42 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>>> I think this is i) from the domination relation:
>>> 
>>> > A record pattern with type R and record component pattern list L dominates another record pattern with type S and record component pattern list M if (i) the erasure of S is a subtype of the erasure of R, and (ii) every pattern, if any, in L dominates the corresponding pattern in M.
>> 
>> But this subtyping test seems to happen at the level of the component pattern list, not at the R/S level, right?
>
> You are right. It is the ii) which iteratively checks the component pattern list L.

I now believe that the check is needed to properly classify patterns based on the type of the i-th component. That said, not sure this should be a subtyping check, or a type equality

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From rriggs at openjdk.java.net  Thu May  5 15:50:24 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 15:50:24 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v4]
In-Reply-To: <jXmjmkVnLhV6WYxtzFPtK6fCemJvucY_ztds-qzL9-Q=.da298ef3-958b-45ae-9acd-08ff733a5b5a@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <1dZ6o94-xt1oOEevAAO3uYDQrjStchH0FfrHi88V1OE=.bbc63a8f-7959-46fa-ad9c-292c09e80ae5@github.com>
 <tRSCLtwhcT3K3Cdy8VZC4qQGS33-Uss4jEUZNlfjeHw=.4a38432f-8fb3-4ad3-9cb4-906f2ceea673@github.com>
 <akwgpvANqHGDDCGK-76rJEvaIfBX2wQ42NaPyHPjq3k=.e6c1ebf3-6d5b-41db-9961-19d99e8d4677@github.com>
 <jXmjmkVnLhV6WYxtzFPtK6fCemJvucY_ztds-qzL9-Q=.da298ef3-958b-45ae-9acd-08ff733a5b5a@github.com>
Message-ID: <WY-sddIEcBIuoMnzbtHINLPaivO-j-YSLUg-PNZJdXI=.c096c5a9-1124-4c33-9e35-6023f18dedb7@github.com>

On Thu, 5 May 2022 15:41:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> If I just use `System.getProperty("sun.jnu.encoding")`, following testcases were failed.
>> 
>> java/lang/ProcessBuilder/SecurityManagerClinit.java 
>> java/lang/ProcessHandle/PermissionTest.java 
>> 
>> Please give me your suggestion again.
>
> Ah, OK. Never mind.

It might be worthwhile to cache the `sun.jnu.encoding` property value in jdk/internal/util/StaticProperty.
And perhaps even cache the Charset (not just the string).

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From rriggs at openjdk.java.net  Thu May  5 15:51:19 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 15:51:19 GMT
Subject: RFR: JDK-8286191: misc tests fail due to JDK-8286191
In-Reply-To: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
References: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
Message-ID: <Ugip1KXFlxB_mNQs88d-QoSNlyfA_Bf1iCQCv39uUuw=.c2d26b70-71a6-4e9f-aedc-6ce140bd9512@github.com>

On Thu, 5 May 2022 15:21:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The isMusl method had to be handled in test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools tests.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8556

From rriggs at openjdk.java.net  Thu May  5 15:52:08 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 15:52:08 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
In-Reply-To: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
Message-ID: <e_sR29d_Zl9ExOEc4SGmHIp2i-CBudv0Jz5WoPajR6o=.424b8572-8f96-48ad-a5b5-6bccc90ccf96@github.com>

On Thu, 5 May 2022 15:30:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

The PR is not needed, the issue will be fixed by PR#8556.

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From rriggs at openjdk.java.net  Thu May  5 15:52:08 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 15:52:08 GMT
Subject: Withdrawn: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
In-Reply-To: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
Message-ID: <-MV5GsnX2_TA6gbscqcAd9hUUDyAHptzeUVbFokmRq0=.fb0a68d1-434f-46a3-8d5d-08e359fa86db@github.com>

On Thu, 5 May 2022 15:30:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From coffeys at openjdk.java.net  Thu May  5 16:08:38 2022
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Thu, 5 May 2022 16:08:38 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
Message-ID: <7N1fimic2Cdh1UG_lIkjdUZhX_r-zzC1equf9VbNU7U=.f43339fb-7797-4d84-9c87-472e6db02638@github.com>

On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

Studied the java.io package edits, the new JFR events and the new jcmd dump_to_file functionality. Looks good!

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

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From jbhateja at openjdk.java.net  Thu May  5 16:09:20 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 5 May 2022 16:09:20 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v2]
In-Reply-To: <MCeN_ZJLMC5Ym1gSkXfGzz4PaSD9uN18tv67UGEtVYE=.1214b583-9d8f-4982-915a-088dc432bc3e@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <MCeN_ZJLMC5Ym1gSkXfGzz4PaSD9uN18tv67UGEtVYE=.1214b583-9d8f-4982-915a-088dc432bc3e@github.com>
Message-ID: <tngG0b8Q20_scOYldUbqwyfP1zQOwzw6VuQc4_3eOW4=.217632f8-001c-4efb-9da9-ac53279d845b@github.com>

On Thu, 5 May 2022 05:47:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - 8284960: Correcting a typo.
>  - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: AARCH64 backend changes.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Integration of JEP 426: Vector API (Fourth Incubator)

Hi @vnkozlov , It will be helpful if you can kindly review the changes.

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

PR: https://git.openjdk.java.net/jdk/pull/8425

From dcubed at openjdk.java.net  Thu May  5 16:18:19 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 5 May 2022 16:18:19 GMT
Subject: RFR: JDK-8286191: misc tests fail due to JDK-8286191
In-Reply-To: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
References: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
Message-ID: <_f5SicAf4gJF5AyC83V155aLg1JliMi0Js3vq_hw_Pc=.d5fd9cb3-9cdd-4c29-8cd6-b3299ce19b7f@github.com>

On Thu, 5 May 2022 15:21:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The isMusl method had to be handled in test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools tests.

Changes requested by dcubed (Reviewer).

test/langtools/jdk/jshell/ExternalEditorTest.java line 29:

> 27:  * @bug 8143955 8080843 8163816 8143006 8169828 8171130 8162989 8210808
> 28:  * @comment musl/Alpine has problems executing some shell scripts, see 8285987
> 29:  * @requires !vm.musl

So this change backs out an "@requires" that was added by:

JDK-8285987 executing shell scripts without #! fails on Alpine linux
https://bugs.openjdk.java.net/browse/JDK-8285987

Presumably this "@requires" was added for some reason so what's
going to happen if this test is run on Alpine Linux? Also, the fix in
JDK-8285987 updated the copyright year. Do you plan on restoring
it to the original "2017" value?

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

PR: https://git.openjdk.java.net/jdk/pull/8556

From naoto at openjdk.java.net  Thu May  5 16:19:34 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 May 2022 16:19:34 GMT
Subject: RFR: 8286154: Fix 3rd party notices in test files
Message-ID: <hLwfE37__3lWiBpqF2v68idqQMNcka-NQFyiGoDVdo8=.63d53f88-33d7-4468-b032-51984746ff4a@github.com>

Trivial fix to 3rd party copyright notices.

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

Commit messages:
 - 8286154: Fix 3rd party notices in test files

Changes: https://git.openjdk.java.net/jdk/pull/8558/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8558&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286154
  Stats: 100 lines in 21 files changed: 64 ins; 0 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8558.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8558/head:pull/8558

PR: https://git.openjdk.java.net/jdk/pull/8558

From darcy at openjdk.java.net  Thu May  5 16:25:18 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 5 May 2022 16:25:18 GMT
Subject: RFR: 8286154: Fix 3rd party notices in test files
In-Reply-To: <hLwfE37__3lWiBpqF2v68idqQMNcka-NQFyiGoDVdo8=.63d53f88-33d7-4468-b032-51984746ff4a@github.com>
References: <hLwfE37__3lWiBpqF2v68idqQMNcka-NQFyiGoDVdo8=.63d53f88-33d7-4468-b032-51984746ff4a@github.com>
Message-ID: <fMu9NMItfzpZZ8NHFdSYPyYNTvm45QBeH5SrNwF1z74=.d5ea653c-ace9-4a36-8e63-3f03e7e84942@github.com>

On Thu, 5 May 2022 16:13:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial fix to 3rd party copyright notices.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8558

From mchung at openjdk.java.net  Thu May  5 16:26:37 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 5 May 2022 16:26:37 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <Z2i25iT-dN2Zez6f6Azb3Xc1UGLGiuSZ_rp5RWSbQMo=.7a902992-b630-452f-aa93-4c1b6ddadf74@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
 <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
 <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>
 <Z2i25iT-dN2Zez6f6Azb3Xc1UGLGiuSZ_rp5RWSbQMo=.7a902992-b630-452f-aa93-4c1b6ddadf74@github.com>
Message-ID: <c6_q4cA5NFTWU1i0OEtwxtdkD-KZQGUiRQxKfv7eDTw=.7cc20b22-b4d0-463a-a0df-0b1021360754@github.com>

On Wed, 4 May 2022 23:44:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module.
>
> Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe.

`BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`).

To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`.

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From joehw at openjdk.java.net  Thu May  5 16:32:16 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 5 May 2022 16:32:16 GMT
Subject: RFR: 8286154: Fix 3rd party notices in test files
In-Reply-To: <hLwfE37__3lWiBpqF2v68idqQMNcka-NQFyiGoDVdo8=.63d53f88-33d7-4468-b032-51984746ff4a@github.com>
References: <hLwfE37__3lWiBpqF2v68idqQMNcka-NQFyiGoDVdo8=.63d53f88-33d7-4468-b032-51984746ff4a@github.com>
Message-ID: <IWhEIFH4auEjgOEMD39Y6UOgy1jZCTWpVqBSyEPcO-w=.5b2d98c1-f6ea-4585-a50f-bd684d162383@github.com>

On Thu, 5 May 2022 16:13:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial fix to 3rd party copyright notices.

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8558

From dcubed at openjdk.java.net  Thu May  5 16:37:18 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 5 May 2022 16:37:18 GMT
Subject: RFR: JDK-8286191: misc tests fail due to JDK-8286191
In-Reply-To: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
References: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
Message-ID: <a_aUkSLw2kwTWrX35PJwwuoTRiI7CB78Zy4WYf-XtXc=.bf9f735c-79b6-47a0-9328-4dd242d1bdc7@github.com>

On Thu, 5 May 2022 15:21:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The isMusl method had to be handled in test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools tests.

@MBaesken - I corrected a typo in my synopsis update for JDK-8286191.
Please use "/issue JDK-8286191" to update the PR's synopsis.

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

PR: https://git.openjdk.java.net/jdk/pull/8556

From mchung at openjdk.java.net  Thu May  5 16:42:25 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 5 May 2022 16:42:25 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <c6_q4cA5NFTWU1i0OEtwxtdkD-KZQGUiRQxKfv7eDTw=.7cc20b22-b4d0-463a-a0df-0b1021360754@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
 <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
 <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>
 <Z2i25iT-dN2Zez6f6Azb3Xc1UGLGiuSZ_rp5RWSbQMo=.7a902992-b630-452f-aa93-4c1b6ddadf74@github.com>
 <c6_q4cA5NFTWU1i0OEtwxtdkD-KZQGUiRQxKfv7eDTw=.7cc20b22-b4d0-463a-a0df-0b1021360754@github.com>
Message-ID: <B8HsKWzG5mzP_q6i3cLSIXZxSbtZQ9ln7kjYwsH2ETI=.6b584339-8a1f-44a8-9cb0-106d970d4940@github.com>

On Thu, 5 May 2022 16:22:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe.
>
> `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`).
> 
> To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`.

When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`.    I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader.  This is consistent with JNI `FindClass` when invoked with no caller frame.

It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class.   However, the existing behavior may likely be unchanged because of the compatibility risk.

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

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From iris at openjdk.java.net  Thu May  5 17:04:13 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 5 May 2022 17:04:13 GMT
Subject: RFR: 8286154: Fix 3rd party notices in test files
In-Reply-To: <hLwfE37__3lWiBpqF2v68idqQMNcka-NQFyiGoDVdo8=.63d53f88-33d7-4468-b032-51984746ff4a@github.com>
References: <hLwfE37__3lWiBpqF2v68idqQMNcka-NQFyiGoDVdo8=.63d53f88-33d7-4468-b032-51984746ff4a@github.com>
Message-ID: <WmQM8_u5rIPd3pCpEEOA1fv4RXwB4IDgUsWStLF8c_A=.bd7e56ec-fe6b-41f2-a7dc-92fb29a2f33b@github.com>

On Thu, 5 May 2022 16:13:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial fix to 3rd party copyright notices.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8558

From darcy at openjdk.java.net  Thu May  5 17:15:49 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 5 May 2022 17:15:49 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
Message-ID: <0ntcEQFUGJN5jQeKnIZrEqQR9CDgkt9aHi-1mzUcKP0=.959c2be4-16c1-4d21-8276-a273e5945658@github.com>

On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From iris at openjdk.java.net  Thu May  5 17:26:23 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 5 May 2022 17:26:23 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v7]
In-Reply-To: <DYlMy7YjEc26N4Sq1LafEauWien3fh3SUY0w6FxNXaY=.5595ded0-3e3c-4ec3-a5bb-0d1455509ef0@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <DYlMy7YjEc26N4Sq1LafEauWien3fh3SUY0w6FxNXaY=.5595ded0-3e3c-4ec3-a5bb-0d1455509ef0@github.com>
Message-ID: <hq1xUfgYMP3mSauO5rV9R9vrUyaa4yi8mmENa-r3Wcg=.ce6dfeab-9f22-45c8-adf3-6c93d271fc09@github.com>

On Wed, 4 May 2022 23:10:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Respond to mbreinhold review feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Update wording to address review feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Change punctuation from review feedback.
>  - Respond to review feedback; make sequence of values explicit.
>  - Respond to review feedback.
>  - Respond to review feedback.
>  - Respond to CSR feedback.
>  - Merge branch 'master' into JDK-8285497
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/460bf5de...7b7720cf

Associated CSR also reviewed.

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8437

From vromero at openjdk.java.net  Thu May  5 17:39:16 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 5 May 2022 17:39:16 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <UCFbYTr1ZOafb18sLjmi7h1X0vdur721OLDSvrba3Lw=.64954b7b-38f4-4b9e-8750-e90e6847edb3@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <UCFbYTr1ZOafb18sLjmi7h1X0vdur721OLDSvrba3Lw=.64954b7b-38f4-4b9e-8750-e90e6847edb3@github.com>
Message-ID: <Xgg7Wh7p5xT8ONeIAFTexGHrailtcndlQBj2IPG1gNI=.938fd89e-bb35-469b-bcae-bc50e21db5ff@github.com>

On Thu, 5 May 2022 15:21:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 64:
> 
>> 62:     public enum Feature {
>> 63:         SWITCH_PATTERN_MATCHING,
>> 64:         DECONSTRUCTION_PATTERNS,
> 
> The spec and JEP talks about record patterns - I think we should follow the correct name here

yup, I agree

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From shade at openjdk.java.net  Thu May  5 17:46:09 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 5 May 2022 17:46:09 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
Message-ID: <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>

On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>  - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec

I am sorry to be a buzzkill here, but this integration would break lots of platforms even when Loom functionality is not enabled/used. For example, running `java -version` on RISC-V runs into many issues: `TemplateInterpreterGenerator::generate_Continuation_doYield_entry` runs into `Unimplemented()`, `UnsafeCopyMemory` asserts about UCM table size, `NativeDeoptInstruction::is_deopt` would run into `Unimplemented()` while being called from signal handler.

This effectively blocks development on those platforms, and it seems to be too much breakage for a preview feature. Are we really breaking these platforms? Do we have plans in place with maintainers of those platforms to fix all this in JDK 19 timeframe? I'd suggest holding off the integration until such a plan and agreement is in place.

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

Changes requested by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8166

From alanb at openjdk.java.net  Thu May  5 19:00:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 May 2022 19:00:42 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
 <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>
Message-ID: <IClQBci8WY_me9QbqEJc1YmrSDb69SSwbs30vvXk0FE=.1952a7e8-af0d-4c56-a6e3-16459a8026bf@github.com>

On Thu, 5 May 2022 17:43:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am sorry to be a buzzkill here, but this integration would break lots of platforms even when Loom functionality is not enabled/used. For example, running `java -version` on RISC-V runs into many issues: `TemplateInterpreterGenerator::generate_Continuation_doYield_entry` runs into `Unimplemented()`, `UnsafeCopyMemory` asserts about UCM table size, `NativeDeoptInstruction::is_deopt` would run into `Unimplemented()` while being called from signal handler.
> 
> This effectively blocks development on those platforms, and it seems to be too much breakage for a preview feature. Are we really breaking these platforms? Do we have plans in place with maintainers of those platforms to fix all this in JDK 19 timeframe? I'd suggest holding off the integration until such a plan and agreement is in place.

We mailed porters-dev in Sep 2021 to give a heads up that this feature would require porting work so it shouldn't be a surprise. We have been open to including other ports with the initial integration but it was never a goal to have all the ports done in advance of that.

Most of the new code in the VM is only used when running with --enable-preview. You'll see several places that test Continuations::enabled(). It should be possible to get these port running without -enable-preview without much effort. The feature has to be implemented to pass all the tests of course.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From dcubed at openjdk.java.net  Thu May  5 19:26:32 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 5 May 2022 19:26:32 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
In-Reply-To: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
Message-ID: <j2slI-tA8Mq-MV6-icXxs5eGeBsJ5ZnqTHDlieJ1_mc=.8cf2fbad-f982-4a15-b5ab-a647e8687c96@github.com>

On Thu, 5 May 2022 15:30:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

Thumbs up (after resync). This is a trivial fix.

test/lib-test/ProblemList.txt line 40:

> 38: #
> 39: #############################################################################
> 40: jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java 8286191 generic-all

This change shouldn't be here. I think you need to update
your repo to sync with your earlier fix.

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From psandoz at openjdk.java.net  Thu May  5 19:30:59 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 5 May 2022 19:30:59 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
Message-ID: <ZU_NGFdXj1afua9vWK7R1W2uHis87SnXhPUegbYqcYw=.50877d5e-7003-4408-8dbd-20ca89ccc442@github.com>

On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename "use_predicate" to "needs_predicate"

src/hotspot/share/opto/vectorIntrinsics.cpp line 1238:

> 1236:     } else {
> 1237:       // Masked vector load with IOOBE always uses the predicated load.
> 1238:       const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int();

Should it be `argument(7)`? (and adjustments later to access the container).

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From rriggs at openjdk.java.net  Thu May  5 19:45:46 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 19:45:46 GMT
Subject: RFR: 8272352: Java launcher can not parse Chinese character when
 system locale is set to UTF-8 [v2]
In-Reply-To: <ZvubpWKgDkV_sWE1YGetOND_xyPFqRBrmO2ezDjudBk=.f55cc1de-d9e3-4d76-b848-9037d9a782ca@github.com>
References: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
 <ZvubpWKgDkV_sWE1YGetOND_xyPFqRBrmO2ezDjudBk=.f55cc1de-d9e3-4d76-b848-9037d9a782ca@github.com>
Message-ID: <tO9HRWqTLvxH-8Hf-SLdoTPISO1l03RbAazAghr3rZU=.17463a19-2ecb-4d6a-9610-c39015d14b69@github.com>

On Tue, 3 May 2022 18:55:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Java runtime has been detecting the Windows system locale encoding using `GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...)`, but it returns the *legacy* ANSI code page value, e.g, 1252 for US-English. In order to detect whether the user has selected `UTF-8` as the default, the code page has to be queried with `GetACP()`.
>> Also, the case if the call to `GetLocaleInfo` fails changed to fall back to `UTF-8` instead of `Cp1252`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Default to UTF-8 if malloc fails

Looks good.

src/java.base/windows/native/libjava/java_props_md.c line 695:

> 693:                            &display_encoding);
> 694: 
> 695:             sprops.sun_jnu_encoding = getEncodingInternal(0);

How should NULL from `getEncodingInternal` be handled?  (only if malloc fails).

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8434

From rriggs at openjdk.java.net  Thu May  5 19:56:36 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 19:56:36 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java [v2]
In-Reply-To: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
Message-ID: <KhcbxWjoLvtri-Q1xGa4_kXF8PbPSInF1Y2C0wJO9wg=.3090bc12-ce87-418c-9356-c120e33c58c5@github.com>

> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

Roger Riggs 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 8286199-problem-jshell
 - 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
 - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8557/files
  - new: https://git.openjdk.java.net/jdk/pull/8557/files/1962634e..cd0d157c

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

  Stats: 656 lines in 10 files changed: 269 ins; 209 del; 178 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8557.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8557/head:pull/8557

PR: https://git.openjdk.java.net/jdk/pull/8557

From rriggs at openjdk.java.net  Thu May  5 19:56:36 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 19:56:36 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java [v2]
In-Reply-To: <j2slI-tA8Mq-MV6-icXxs5eGeBsJ5ZnqTHDlieJ1_mc=.8cf2fbad-f982-4a15-b5ab-a647e8687c96@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
 <j2slI-tA8Mq-MV6-icXxs5eGeBsJ5ZnqTHDlieJ1_mc=.8cf2fbad-f982-4a15-b5ab-a647e8687c96@github.com>
Message-ID: <A3ndGjxg4YA3-UMR65VC0hJH5lmRhi-sKBdISCPleTA=.30609e3b-3980-4fb0-aa42-ee04e1487f33@github.com>

On Thu, 5 May 2022 19:23:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Roger Riggs 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 8286199-problem-jshell
>>  - 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
>>  - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java
>
> test/lib-test/ProblemList.txt line 40:
> 
>> 38: #
>> 39: #############################################################################
>> 40: jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java 8286191 generic-all
> 
> This change shouldn't be here. I think you need to update
> your repo to sync with your earlier fix.

Updated, after the merge only the langtools ProblemList.txt is modified

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From rriggs at openjdk.java.net  Thu May  5 20:02:47 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 20:02:47 GMT
Subject: RFR: 8272352: Java launcher can not parse Chinese character when
 system locale is set to UTF-8 [v2]
In-Reply-To: <tO9HRWqTLvxH-8Hf-SLdoTPISO1l03RbAazAghr3rZU=.17463a19-2ecb-4d6a-9610-c39015d14b69@github.com>
References: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
 <ZvubpWKgDkV_sWE1YGetOND_xyPFqRBrmO2ezDjudBk=.f55cc1de-d9e3-4d76-b848-9037d9a782ca@github.com>
 <tO9HRWqTLvxH-8Hf-SLdoTPISO1l03RbAazAghr3rZU=.17463a19-2ecb-4d6a-9610-c39015d14b69@github.com>
Message-ID: <9Uht7b0tdHa9T5tQLs5x1FNG_TaFodgFGPLFHYx4lBM=.86178dea-5d4b-4fd8-8190-ae5049dae640@github.com>

On Tue, 3 May 2022 16:17:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Default to UTF-8 if malloc fails
>
> src/java.base/windows/native/libjava/java_props_md.c line 695:
> 
>> 693:                            &display_encoding);
>> 694: 
>> 695:             sprops.sun_jnu_encoding = getEncodingInternal(0);
> 
> How should NULL from `getEncodingInternal` be handled?  (only if malloc fails).

Ignore the repeated comment.  The code looks fine.

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

PR: https://git.openjdk.java.net/jdk/pull/8434

From naoto at openjdk.java.net  Thu May  5 20:02:48 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 May 2022 20:02:48 GMT
Subject: Integrated: 8272352: Java launcher can not parse Chinese character
 when system locale is set to UTF-8
In-Reply-To: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
References: <TTvXNy9r4fqc429n6C2J37Ji-dEa6GVD9XpErY1Wqdk=.dd82d7da-9516-401a-a34e-f75973f9cd40@github.com>
Message-ID: <hbmLq_mMlrVottdTzlMGQqAI1IooE4OGV2PSLMoXmPM=.0354b73e-8736-4019-b8a1-930200b97563@github.com>

On Wed, 27 Apr 2022 20:23:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Java runtime has been detecting the Windows system locale encoding using `GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...)`, but it returns the *legacy* ANSI code page value, e.g, 1252 for US-English. In order to detect whether the user has selected `UTF-8` as the default, the code page has to be queried with `GetACP()`.
> Also, the case if the call to `GetLocaleInfo` fails changed to fall back to `UTF-8` instead of `Cp1252`.

This pull request has now been integrated.

Changeset: 22934485
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/229344853126692d38ff7cb164dd5d17c5bf7fbb
Stats:     15 lines in 1 file changed: 6 ins; 4 del; 5 mod

8272352: Java launcher can not parse Chinese character when system locale is set to UTF-8

Reviewed-by: rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/8434

From dcubed at openjdk.java.net  Thu May  5 20:06:59 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 5 May 2022 20:06:59 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java [v2]
In-Reply-To: <KhcbxWjoLvtri-Q1xGa4_kXF8PbPSInF1Y2C0wJO9wg=.3090bc12-ce87-418c-9356-c120e33c58c5@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
 <KhcbxWjoLvtri-Q1xGa4_kXF8PbPSInF1Y2C0wJO9wg=.3090bc12-ce87-418c-9356-c120e33c58c5@github.com>
Message-ID: <X2YJGs4rqJmZxMXdEj68KmiTJKn4PEtXBeDehHhZ0Io=.5c4a2188-1ff6-4232-8b12-0eca8510c35a@github.com>

On Thu, 5 May 2022 19:56:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.
>
> Roger Riggs 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 8286199-problem-jshell
>  - 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
>  - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

Thumbs up. This is a trivial fix.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8557

From rriggs at openjdk.java.net  Thu May  5 20:06:59 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 20:06:59 GMT
Subject: RFR: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java [v2]
In-Reply-To: <KhcbxWjoLvtri-Q1xGa4_kXF8PbPSInF1Y2C0wJO9wg=.3090bc12-ce87-418c-9356-c120e33c58c5@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
 <KhcbxWjoLvtri-Q1xGa4_kXF8PbPSInF1Y2C0wJO9wg=.3090bc12-ce87-418c-9356-c120e33c58c5@github.com>
Message-ID: <08JP1LQ73JAFDNdsgBjfx3QUdPORyet98rCcHCdCBvs=.f7b00a4a-a979-4c9f-995c-b4163ced7550@github.com>

On Thu, 5 May 2022 19:56:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.
>
> Roger Riggs 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 8286199-problem-jshell
>  - 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
>  - 8286195: ProblemList test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

ProblemListing the test to clean up the CI.
#8556 seems to have been delayed

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From rriggs at openjdk.java.net  Thu May  5 20:07:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 May 2022 20:07:01 GMT
Subject: Integrated: 8286199: ProblemList jdk/jshell/ExternalEditorTest.java
In-Reply-To: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
References: <zF7Q7tJplGlKMhEpd-cPyVtvIBSxcANF4nJOOiS9k9Q=.b94f5f02-8191-480f-bb91-4e0664854c83@github.com>
Message-ID: <iqXAqtRkfp4Clh15adhHYvpRLiRfqFlZwxqyDjZsmzc=.29a9606b-2afd-4809-8aba-7e038dd4bde0@github.com>

On Thu, 5 May 2022 15:30:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Put jdk/jshell/ExternalEditorTest.java on the problem list due to 8286191.

This pull request has now been integrated.

Changeset: 2f995c8d
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2f995c8d2b8650e45e6a360f3c958bfaf46b2ef3
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8286199: ProblemList jdk/jshell/ExternalEditorTest.java

Reviewed-by: dcubed

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

PR: https://git.openjdk.java.net/jdk/pull/8557

From asemenyuk at openjdk.java.net  Thu May  5 20:09:37 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 5 May 2022 20:09:37 GMT
Subject: RFR: 8285616: [macos] Incorrect path for launcher-as-service.txt in
 .cfg file
Message-ID: <jzLIh8ST48gqyz_pGYvEyCyY2kwhJQ2WmS0VTs6jyow=.3458440f-f469-4fd0-a8bf-01594c1fa0fa@github.com>

- Replace `System.getProperty("java.io.tmpdir")` call with hardcoded `/tmp` string to get root folder for test files.
- Fix test cleanup - the test didn't delete test files upon completion

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

Commit messages:
 - 8285616: [macos] Incorrect path for launcher-as-service.txt in .cfg file

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

PR: https://git.openjdk.java.net/jdk/pull/8563

From almatvee at openjdk.java.net  Thu May  5 20:21:50 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 5 May 2022 20:21:50 GMT
Subject: RFR: 8285616: [macos] Incorrect path for launcher-as-service.txt
 in .cfg file
In-Reply-To: <jzLIh8ST48gqyz_pGYvEyCyY2kwhJQ2WmS0VTs6jyow=.3458440f-f469-4fd0-a8bf-01594c1fa0fa@github.com>
References: <jzLIh8ST48gqyz_pGYvEyCyY2kwhJQ2WmS0VTs6jyow=.3458440f-f469-4fd0-a8bf-01594c1fa0fa@github.com>
Message-ID: <R-7RNdm5AFRhtyzkL6Nr4DqBDQOajlj-Zbfeb6YdBWk=.0e45313d-6646-4489-9692-8b28e4b71fd6@github.com>

On Thu, 5 May 2022 20:00:54 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Replace `System.getProperty("java.io.tmpdir")` call with hardcoded `/tmp` string to get root folder for test files.
> - Fix test cleanup - the test didn't delete test files upon completion

Marked as reviewed by almatvee (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8563

From asemenyuk at openjdk.java.net  Thu May  5 20:26:52 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 5 May 2022 20:26:52 GMT
Subject: Integrated: 8285616: [macos] Incorrect path for
 launcher-as-service.txt in .cfg file
In-Reply-To: <jzLIh8ST48gqyz_pGYvEyCyY2kwhJQ2WmS0VTs6jyow=.3458440f-f469-4fd0-a8bf-01594c1fa0fa@github.com>
References: <jzLIh8ST48gqyz_pGYvEyCyY2kwhJQ2WmS0VTs6jyow=.3458440f-f469-4fd0-a8bf-01594c1fa0fa@github.com>
Message-ID: <k8R9UQNpkIFK9_uDz22kigZdPtrCRJrtU4ypPotqWFQ=.77eed0ce-86ca-48dd-91fa-cc53d74796cc@github.com>

On Thu, 5 May 2022 20:00:54 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - Replace `System.getProperty("java.io.tmpdir")` call with hardcoded `/tmp` string to get root folder for test files.
> - Fix test cleanup - the test didn't delete test files upon completion

This pull request has now been integrated.

Changeset: 9644a314
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9644a314cf1c80e43c48474f6f311fc98da597ac
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8285616: [macos] Incorrect path for launcher-as-service.txt in .cfg file

Reviewed-by: almatvee

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

PR: https://git.openjdk.java.net/jdk/pull/8563

From mcimadamore at openjdk.java.net  Thu May  5 20:54:53 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 May 2022 20:54:53 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v39]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <gEIYNc5S2KxVCScOlOJcrUp5Fdlkjw1N6qykKYot4Kw=.b692629a-f9f5-45c0-9127-cdb7fdeebe6c@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

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

  * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
  * Tweak restricted method check to work when there's no caller class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/853f06b8..4d24ffa9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=38
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=37-38

  Stats: 22 lines in 2 files changed: 16 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Thu May  5 20:54:55 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 May 2022 20:54:55 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v37]
In-Reply-To: <B8HsKWzG5mzP_q6i3cLSIXZxSbtZQ9ln7kjYwsH2ETI=.6b584339-8a1f-44a8-9cb0-106d970d4940@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <Obq3_W0dnbEo9deFiDYrfKr8BJ78eL-R-OnXDtaQxX4=.2c65b6dd-5871-4117-ac7c-1f38fa8fad40@github.com>
 <koNDdOWusRGPhkECAKNmV9-tye1-u_cNeef2iZHgxqg=.0d5aaf86-ae8f-422f-a020-6e6ab8111893@github.com>
 <FgzRkHIv2zljKVpABBGr4Ja27w1WEKY5PfFOPYnv1O0=.28baa00b-814f-45de-b68f-8652cf650977@github.com>
 <p2MOOM1OLO9Npizn-jLUtg4E6YYjfLu1eM1j-GHWbH4=.6d070381-cb92-4470-86c6-11afb0ab51dc@github.com>
 <Z2i25iT-dN2Zez6f6Azb3Xc1UGLGiuSZ_rp5RWSbQMo=.7a902992-b630-452f-aa93-4c1b6ddadf74@github.com>
 <c6_q4cA5NFTWU1i0OEtwxtdkD-KZQGUiRQxKfv7eDTw=.7cc20b22-b4d0-463a-a0df-0b1021360754@github.com>
 <B8HsKWzG5mzP_q6i3cLSIXZxSbtZQ9ln7kjYwsH2ETI=.6b584339-8a1f-44a8-9cb0-106d970d4940@github.com>
Message-ID: <-zAvw8aE9e94OWQyDLUT3IqPzKJFT3v0x_HQVJObonc=.3370a3b7-e797-439f-8a72-ff6d3ec59be4@github.com>

On Thu, 5 May 2022 16:39:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`).
>> 
>> To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`.
>
> When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`.    I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader.  This is consistent with JNI `FindClass` when invoked with no caller frame.
> 
> It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class.   However, the existing behavior may likely be unchanged because of the compatibility risk.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8281001

Thanks for the comments. I've pushed a new change which fixes a couple of thing:

* first, for `SymbolLookup.loaderLookup`, the system class loader is used when no caller class exists (e.g. when method is called from JNI). If caller class exist but its loader is null (boot loader), we just call ClassLoader::findNative with a `null` loader which will do the right thing (thanks @mlchung for the tips!)

* second, the restricted method check in `Reflection::ensureNativeAccess` has been improved to also work in case where caller class is `null`. In such cases, a dummy unnamed module module is used for the check.

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From mr at openjdk.java.net  Thu May  5 21:33:54 2022
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 5 May 2022 21:33:54 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v7]
In-Reply-To: <DYlMy7YjEc26N4Sq1LafEauWien3fh3SUY0w6FxNXaY=.5595ded0-3e3c-4ec3-a5bb-0d1455509ef0@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
 <DYlMy7YjEc26N4Sq1LafEauWien3fh3SUY0w6FxNXaY=.5595ded0-3e3c-4ec3-a5bb-0d1455509ef0@github.com>
Message-ID: <sJlSg9Hy48yxdyl6zTKjUC_CC1DyzZuCnoLaru8W4DY=.a9ec7de0-3249-4bf6-be06-263738a3d891@github.com>

On Wed, 4 May 2022 23:10:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
>> 
>> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
>> 
>> I'll update copyright years before an integration.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Respond to mbreinhold review feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Update wording to address review feedback.
>  - Merge branch 'master' into JDK-8285497
>  - Change punctuation from review feedback.
>  - Respond to review feedback; make sequence of values explicit.
>  - Respond to review feedback.
>  - Respond to review feedback.
>  - Respond to CSR feedback.
>  - Merge branch 'master' into JDK-8285497
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f3cf898e...7b7720cf

Changes requested by mr (Lead).

src/java.base/share/classes/java/lang/System.java line 790:

> 788:      * href="https://jcp.org/en/procedures/jcp2#3.6.4">maintenance
> 789:      * release</a>. When defined, its value identifies that
> 790:      * maintenance release. To indicate the first maintenance release

The final sentence can be shortened, and looking at it now the semicolon should just be a comma:

     * maintenance release. To indicate the first maintenance release
     * this property will have the value {@code "1"}, to indicate the
     * second maintenance release it will have the value {@code "2"},
     * and so on.

Otherwise, this looks good to me.

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

PR: https://git.openjdk.java.net/jdk/pull/8437

From mchung at openjdk.java.net  Thu May  5 21:34:54 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 5 May 2022 21:34:54 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v39]
In-Reply-To: <gEIYNc5S2KxVCScOlOJcrUp5Fdlkjw1N6qykKYot4Kw=.b692629a-f9f5-45c0-9127-cdb7fdeebe6c@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <gEIYNc5S2KxVCScOlOJcrUp5Fdlkjw1N6qykKYot4Kw=.b692629a-f9f5-45c0-9127-cdb7fdeebe6c@github.com>
Message-ID: <aImM-95p05F3f-XDzASkz3T9U8L_zi0XUTpqmGsyq9o=.5a4ae8f0-35a7-4da1-b1e5-01efcc4d16af@github.com>

On Thu, 5 May 2022 20:54:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
>   * Tweak restricted method check to work when there's no caller class

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 161:

> 159:                 ClassLoader.getSystemClassLoader();
> 160:         MemorySession loaderSession = (loader == null) ?
> 161:                 MemorySession.global() : // boot loader never goes away

The other built-in class loaders (`ClassLoaders::appClassLoader` and `ClassLoaders::platformClassLoader` are both instance of `BuiltinClassLoader`) will never be unloaded.   Should they use the globel memory session?

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120:

> 118:         // if there is no caller class, act as if the call came from an unnamed module
> 119:         Module module = currentClass != null ?
> 120:                 currentClass.getModule() : Holder.FALLBACK_MODULE;

This can be simplified to:

Module module = currentClass != null ?
               currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule();


No need to have the Holder class.

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From darcy at openjdk.java.net  Thu May  5 22:28:47 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 5 May 2022 22:28:47 GMT
Subject: RFR: JDK-8285497: Add system property for Java SE specification
 maintenance version [v8]
In-Reply-To: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
Message-ID: <olsvUXtfDTSaFWuzPWvHPNAtP_4yGRCfht6VhyHy4fE=.86dca6a5-9b20-40ea-ab8a-87a40bf89e4c@github.com>

> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
> 
> I'll update copyright years before an integration.

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

 - Respond to review feedback and update copyrights.
 - Merge branch 'master' into JDK-8285497
 - Respond to mbreinhold review feedback.
 - Merge branch 'master' into JDK-8285497
 - Update wording to address review feedback.
 - Merge branch 'master' into JDK-8285497
 - Change punctuation from review feedback.
 - Respond to review feedback; make sequence of values explicit.
 - Respond to review feedback.
 - Respond to review feedback.
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/796f256f...28ff456b

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8437/files
  - new: https://git.openjdk.java.net/jdk/pull/8437/files/7b7720cf..28ff456b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8437&range=06-07

  Stats: 1430 lines in 53 files changed: 600 ins; 493 del; 337 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437

PR: https://git.openjdk.java.net/jdk/pull/8437

From darcy at openjdk.java.net  Thu May  5 22:28:48 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 5 May 2022 22:28:48 GMT
Subject: Integrated: JDK-8285497: Add system property for Java SE specification
 maintenance version
In-Reply-To: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
References: <zBOly-EDXjC1RrFIOpMjsR7qQqtPs62vH3_JmmJ3BCg=.118fa0c8-8560-412d-9cb5-baf4d2b3f52d@github.com>
Message-ID: <-dAbrliaYQ6GcispxAo1jkbStXNRZvdsEnhVQfbos7I=.08e8bfcd-489c-409f-8c80-db57a25bb643@github.com>

On Wed, 27 Apr 2022 22:27:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Add a new system property, java.specification.maintenance.version, to return the maintenance release number of the Java SE specification being implemented. The property is unset, optional in the terminology of System.getProperties, for an initial release of a specification.
> 
> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764
> 
> I'll update copyright years before an integration.

This pull request has now been integrated.

Changeset: 59ef76a3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/59ef76a365eafe40d8d68b4d5e028f0e731abd01
Stats:     23 lines in 4 files changed: 22 ins; 0 del; 1 mod

8285497: Add system property for Java SE specification maintenance version

Reviewed-by: mullan, jpai, iris

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

PR: https://git.openjdk.java.net/jdk/pull/8437

From duke at openjdk.java.net  Thu May  5 22:29:50 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 5 May 2022 22:29:50 GMT
Subject: Integrated: 8286029: Add classpath exemption to
 globals_vectorApiSupport_***.S.inc
In-Reply-To: <ie0pBgdXLFBTrs_Eg5eTOxoQiSbVaiWOC3vR45kdHxs=.3b79d9d7-4216-4bff-ac47-0ab710c42416@github.com>
References: <ie0pBgdXLFBTrs_Eg5eTOxoQiSbVaiWOC3vR45kdHxs=.3b79d9d7-4216-4bff-ac47-0ab710c42416@github.com>
Message-ID: <pvucJn1j_oAPnG98nJkr22GlrVgg8ZxnLA3Oprv4BOc=.d91614eb-1c92-4b19-97f6-b84fddf662ae@github.com>

On Mon, 2 May 2022 20:05:36 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> Adds missing classpath exception to the header of two GPLv2 files.
> 
> Requested [here](https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2022-April/013988.html).

This pull request has now been integrated.

Changeset: 6a1b145a
Author:    Tyler Steele <tyler.steele at ibm.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6a1b145a0ab0057037f813f7dd6e71ad5b6f3de2
Stats:     8 lines in 2 files changed: 4 ins; 0 del; 4 mod

8286029: Add classpath exemption to globals_vectorApiSupport_***.S.inc

Reviewed-by: sviswanathan

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

PR: https://git.openjdk.java.net/jdk/pull/8508

From smarks at openjdk.java.net  Thu May  5 23:11:50 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 5 May 2022 23:11:50 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v4]
In-Reply-To: <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
Message-ID: <9Qg2ACSSQ1V9qDoVJI6ISindarAi-nZcU_vrECM6Ipo=.56e185d4-9726-4975-9068-1e7bb5a7605f@github.com>

On Wed, 4 May 2022 19:16:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some assertions for entrySet.equals and keySet.equals

Thanks Jaikiran. Could I have a Reviewer take a look at this please?

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From bpb at openjdk.java.net  Thu May  5 23:39:30 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 5 May 2022 23:39:30 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v3]
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <3eDsmvMyBrMn89BpVmMcG6Xyb3m5vM8DzKV-vDhxFXY=.a1553712-81f4-4434-9522-e7dbd7fbbb60@github.com>

> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.

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

 - 6478546: Clean up io_util.c
 - Merge
 - 6478546: Decrease malloc'ed buffer maximum size to 64 kB
 - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8235/files
  - new: https://git.openjdk.java.net/jdk/pull/8235/files/40d46f8f..5c3a3446

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

  Stats: 36827 lines in 1404 files changed: 26452 ins; 4333 del; 6042 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8235.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8235/head:pull/8235

PR: https://git.openjdk.java.net/jdk/pull/8235

From bpb at openjdk.java.net  Thu May  5 23:39:31 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 5 May 2022 23:39:31 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v2]
In-Reply-To: <0zR33ntmiokMzGO30dIGrNQi0x3lX20q_vwQCfaTujU=.9ffa2c8f-fafc-4349-b50a-958c56280ef8@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <0zR33ntmiokMzGO30dIGrNQi0x3lX20q_vwQCfaTujU=.9ffa2c8f-fafc-4349-b50a-958c56280ef8@github.com>
Message-ID: <vswVZcnd-3KAfphSmrKdWEKAIUooFeoYw48KY1sKkro=.64bf2ab7-a499-4193-88b5-7cd26ccd01c7@github.com>

On Thu, 28 Apr 2022 20:02:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6478546: Decrease malloc'ed buffer maximum size to 64 kB

Further performance testing was conducted for the case where the native read and write functions used a fixed, stack-allocated buffer of size 8192. The loops were moved up into the Java code of `FileInputStream`, `FileOutputStream` and `RandomAccessFile`. Note that there was code duplication because RAF needs both read and write methods as well. The performance of writing with this approach was approximately half what it had been, so for writing the approach was abandoned.

Here are some updated performance measurements:

<img width="721" alt="FileInputStream-read-perf" src="https://user-images.githubusercontent.com/71468245/167041493-6d4c421c-c2ec-4a8a-8b32-09b2a902a77c.png">

<img width="720" alt="FileOutputStream-write-perf" src="https://user-images.githubusercontent.com/71468245/167041541-94e5806c-de86-4e62-a117-4cfafac82e87.png">

The performance measurements shown are for the following cases:

1. Master: unmodified code as it exists in the mainline
2. Java: fixed-size stack buffer in native read, read loops in Java, write as in the mainline but with malloc buffer size limit
3. Native: read loop in native read with malloc buffer size limit, write as in the mainline but with malloc buffer size limit

The horizontal axis represents a variety of lengths from 8192 to 1GB; the vertical axis is throughput (ops/s) on a log 10 scale. The native lines in the charts are for the code proposed to be integrated.

As can be seen, the performance of reading is quite similar up to larger lengths. The mainline version presumably starts to suffer the effect of large allocations. The native read loop performs the best throughout, being for lengths 10 MB and above from 50% to 3X faster than the mainline version. The native read loop is about 40% faster than the Java read loop for these larger lengths.

Due to the log scale of the charts, the reading performance detail cannot be seen exactly and so is given here for the larger lengths:


               Throughput of read(byte[]) (ops/s)
   Length      Master         Java        Native
   1048576    11341.39      6124.482    11371.091
  10485760      356.893      376.326      557.906
 251503002       10.036       14.27        19.869
 524288000        5.005        6.857        9.552
1000000000        1.675        3.527        4.997

The performance of writing is about the same for the Java and Native versions, as it should be since the implementations are the same. Any difference is likely due to measurement noise. The mainline version again suffers for larger lengths.

As the native write loop was already present in the mainline code, the principal complexity proposed to be added is the native read loop. Given the improved throughput and vastly reduced native memory allocation this seems to be justified.

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

PR: https://git.openjdk.java.net/jdk/pull/8235

From smarks at openjdk.java.net  Thu May  5 23:49:49 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 5 May 2022 23:49:49 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v4]
In-Reply-To: <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
Message-ID: <ExSU35YKEIy5tpdY15m90ooSlu1XJ44KXK4drfOlA5Y=.831108e2-fdcf-45ba-a2d1-99a9b082e43f@github.com>

On Wed, 4 May 2022 19:16:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some assertions for entrySet.equals and keySet.equals

> There should probably be something like [test/jdk/java/util/Collections/Wrappers.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/Collections/Wrappers.java)

Maybe. The intent of the test is fine, which is to ensure that a default method doesn't get added that breaks the invariants of the wrapper. One problem is that it tests only the default methods of `Collection` and not of the other collections interfaces. Another is that "override all default methods" isn't exactly the right criterion; instead, the criterion should be "override all default methods that would otherwise break this collection's invariants." It would be nice if such a test could be written, but as it stands I think that `Wrappers.java` test is too simplistic.

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From bpb at openjdk.java.net  Fri May  6 01:05:50 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 6 May 2022 01:05:50 GMT
Subject: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java
 fails with expected [true] but found [false]
In-Reply-To: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
References: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
Message-ID: <yeA2fVHWRvNrHeBrnZenwY82fG-i_DZsSAUCi8hhbTY=.d43409c0-b813-4184-ad1d-ed899df75d0a@github.com>

On Tue, 19 Apr 2022 08:40:51 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review these small changes to address intermittent failures, as of JDK-8274517.
> 
> - Usage of jdk.test.lib.RandomFactory for reproducible random generation.
> - Slightly less restrictive assertion about badParallelStreamError on L94 (former L88).
> - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18.
> 
> While these changes do not necessarily guarantee absence of intermittent failures, the usage of jdk.test.lib.RandomFactory should at least help to pin down specific double sequences that do not pass the test.
> 
> There is still an inherent variability due to the use of parallel streams, though. As double addition is not perfectly associative, even a fully known sequence of doubles may lead to slightly different results with parallelization.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8290

From xgong at openjdk.java.net  Fri May  6 03:51:01 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 6 May 2022 03:51:01 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <ZU_NGFdXj1afua9vWK7R1W2uHis87SnXhPUegbYqcYw=.50877d5e-7003-4408-8dbd-20ca89ccc442@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <ZU_NGFdXj1afua9vWK7R1W2uHis87SnXhPUegbYqcYw=.50877d5e-7003-4408-8dbd-20ca89ccc442@github.com>
Message-ID: <PSsn8b0tFvdfFfNw1s0EqBdxgqv0BTL3smIABpPRhIU=.98db7e11-6220-401b-b03a-abc6380d622d@github.com>

On Thu, 5 May 2022 19:27:47 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename "use_predicate" to "needs_predicate"
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1238:
> 
>> 1236:     } else {
>> 1237:       // Masked vector load with IOOBE always uses the predicated load.
>> 1238:       const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int();
> 
> Should it be `argument(7)`? (and adjustments later to access the container).

I'm afraid it's `argument(8)` for the load operation since the `argument(7)` is the mask input. It seems the argument number is not right begin from the mask input which is expected to be `6`. But the it's not. Actually I don't quite understand why.

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From sviswanathan at openjdk.java.net  Fri May  6 04:25:49 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 6 May 2022 04:25:49 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <PSsn8b0tFvdfFfNw1s0EqBdxgqv0BTL3smIABpPRhIU=.98db7e11-6220-401b-b03a-abc6380d622d@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <ZU_NGFdXj1afua9vWK7R1W2uHis87SnXhPUegbYqcYw=.50877d5e-7003-4408-8dbd-20ca89ccc442@github.com>
 <PSsn8b0tFvdfFfNw1s0EqBdxgqv0BTL3smIABpPRhIU=.98db7e11-6220-401b-b03a-abc6380d622d@github.com>
Message-ID: <lgRc3_J4AFK0NPUD0_EuiAwUWj_d4Ka6FzXH3npBARY=.21cf89ef-f605-4f40-b59f-7c57a1faf1d4@github.com>

On Fri, 6 May 2022 03:47:47 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 1238:
>> 
>>> 1236:     } else {
>>> 1237:       // Masked vector load with IOOBE always uses the predicated load.
>>> 1238:       const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int();
>> 
>> Should it be `argument(7)`? (and adjustments later to access the container).
>
> I'm afraid it's `argument(8)` for the load operation since the `argument(7)` is the mask input. It seems the argument number is not right begin from the mask input which is expected to be `6`. But the it's not. Actually I don't quite understand why.

offset is long so uses two argument slots (5 and 6). 
mask is argument (7).
offsetInRange is argument(8).

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Fri May  6 04:52:56 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 6 May 2022 04:52:56 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <lgRc3_J4AFK0NPUD0_EuiAwUWj_d4Ka6FzXH3npBARY=.21cf89ef-f605-4f40-b59f-7c57a1faf1d4@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <ZU_NGFdXj1afua9vWK7R1W2uHis87SnXhPUegbYqcYw=.50877d5e-7003-4408-8dbd-20ca89ccc442@github.com>
 <PSsn8b0tFvdfFfNw1s0EqBdxgqv0BTL3smIABpPRhIU=.98db7e11-6220-401b-b03a-abc6380d622d@github.com>
 <lgRc3_J4AFK0NPUD0_EuiAwUWj_d4Ka6FzXH3npBARY=.21cf89ef-f605-4f40-b59f-7c57a1faf1d4@github.com>
Message-ID: <OGo9aUs8yLmsxC1eoalXA3G6yC7U9aEVtkUqrussqCc=.3385b881-7225-4552-aa5a-47a30968afdd@github.com>

On Fri, 6 May 2022 04:22:30 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> I'm afraid it's `argument(8)` for the load operation since the `argument(7)` is the mask input. It seems the argument number is not right begin from the mask input which is expected to be `6`. But the it's not. Actually I don't quite understand why.
>
> offset is long so uses two argument slots (5 and 6). 
> mask is argument (7).
> offsetInRange is argument(8).

Make sense! Thanks for the explanation!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From mbaesken at openjdk.java.net  Fri May  6 06:39:41 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 6 May 2022 06:39:41 GMT
Subject: RFR: 8286191: misc tests fail due to JDK-8285987 [v2]
In-Reply-To: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
References: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
Message-ID: <NpEszZM1iAHr9UXKnQhykv4OqR-hq91_h-p4XFE7-SM=.1eddc94e-e52b-4002-b9de-5d1e189906fd@github.com>

> The isMusl method had to be handled in test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools tests.

Matthias Baesken 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 remote-tracking branch 'origin/master' into JDK-8286191
 - remove from ProblemList
 - Merge remote-tracking branch 'origin/master' into JDK-8286191
 - JDK-8286191

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8556/files
  - new: https://git.openjdk.java.net/jdk/pull/8556/files/afdc9797..96f508df

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

  Stats: 515 lines in 30 files changed: 194 ins; 107 del; 214 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8556.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8556/head:pull/8556

PR: https://git.openjdk.java.net/jdk/pull/8556

From mbaesken at openjdk.java.net  Fri May  6 06:41:31 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 6 May 2022 06:41:31 GMT
Subject: RFR: 8286191: misc tests fail due to JDK-8285987 [v3]
In-Reply-To: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
References: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
Message-ID: <1u1FHB8_n-lQP-zR0SdH4m96CnPIMP8sFggRy2xrO30=.c35adb85-09d7-4b06-963c-c745df5930eb@github.com>

> The isMusl method had to be handled in test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools tests.

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

  restore year in ExternalEditorTest, remove test exclusion

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8556/files
  - new: https://git.openjdk.java.net/jdk/pull/8556/files/96f508df..2337301c

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

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

PR: https://git.openjdk.java.net/jdk/pull/8556

From duke at openjdk.java.net  Fri May  6 06:42:02 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Fri, 6 May 2022 06:42:02 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v4]
In-Reply-To: <ExSU35YKEIy5tpdY15m90ooSlu1XJ44KXK4drfOlA5Y=.831108e2-fdcf-45ba-a2d1-99a9b082e43f@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
 <ExSU35YKEIy5tpdY15m90ooSlu1XJ44KXK4drfOlA5Y=.831108e2-fdcf-45ba-a2d1-99a9b082e43f@github.com>
Message-ID: <8HuAzza3YiN-q1ffL_7BeVmxBYEavXgqNgPSaWUb1Mk=.dc42ee03-b285-47fc-b9cb-de364f4960fd@github.com>

On Thu, 5 May 2022 23:46:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> It would be nice if such a test could be written, but as it stands I think that `Wrappers.java` test is too simplistic.

Would adding `Wrappers.java` a method-name white-list mechanism suitable in this situation?

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From mbaesken at openjdk.java.net  Fri May  6 06:47:29 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 6 May 2022 06:47:29 GMT
Subject: RFR: 8286191: misc tests fail due to JDK-8285987
In-Reply-To: <a_aUkSLw2kwTWrX35PJwwuoTRiI7CB78Zy4WYf-XtXc=.bf9f735c-79b6-47a0-9328-4dd242d1bdc7@github.com>
References: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
 <a_aUkSLw2kwTWrX35PJwwuoTRiI7CB78Zy4WYf-XtXc=.bf9f735c-79b6-47a0-9328-4dd242d1bdc7@github.com>
Message-ID: <5xL5bVm_0d6fig3F8PhzcLPBVyKxKQ47CxdBqu8UV3I=.8aceae36-4bbe-46cf-8bb1-44d3ddccf49e@github.com>

On Thu, 5 May 2022 16:33:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> ...  update the PR's synopsis.
Done .

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

PR: https://git.openjdk.java.net/jdk/pull/8556

From mbaesken at openjdk.java.net  Fri May  6 06:47:37 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 6 May 2022 06:47:37 GMT
Subject: RFR: 8286191: misc tests fail due to JDK-8285987 [v3]
In-Reply-To: <_f5SicAf4gJF5AyC83V155aLg1JliMi0Js3vq_hw_Pc=.d5fd9cb3-9cdd-4c29-8cd6-b3299ce19b7f@github.com>
References: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
 <_f5SicAf4gJF5AyC83V155aLg1JliMi0Js3vq_hw_Pc=.d5fd9cb3-9cdd-4c29-8cd6-b3299ce19b7f@github.com>
Message-ID: <k1-iT88lKuYtRFU9yYj5EVelTgqoVckR6CaCBEwv35M=.64aac648-6ae3-4655-85f0-63ab9cae2da3@github.com>

On Thu, 5 May 2022 16:14:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore year in ExternalEditorTest, remove test exclusion
>
> test/langtools/jdk/jshell/ExternalEditorTest.java line 29:
> 
>> 27:  * @bug 8143955 8080843 8163816 8143006 8169828 8171130 8162989 8210808
>> 28:  * @comment musl/Alpine has problems executing some shell scripts, see 8285987
>> 29:  * @requires !vm.musl
> 
> So this change backs out an "@requires" that was added by:
> 
> JDK-8285987 executing shell scripts without #! fails on Alpine linux
> https://bugs.openjdk.java.net/browse/JDK-8285987
> 
> Presumably this "@requires" was added for some reason so what's
> going to happen if this test is run on Alpine Linux? Also, the fix in
> JDK-8285987 updated the copyright year. Do you plan on restoring
> it to the original "2017" value?

Hi Daniel, I restored the original year 2017.
(additionally I removed the langtools exclusion)

> Presumably this "@requires" was added for some reason so what's going to happen if this test is run on Alpine Linux

I can only speak about our Alpine setup (3.15 in a container) and there the test fails with   error=8, Exec format error. Looks like something similar has been observed as well by these people
https://www.openwall.com/lists/musl/2018/03/09/2
https://github.com/scala-steward-org/scala-steward/issues/1374

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

PR: https://git.openjdk.java.net/jdk/pull/8556

From alanb at openjdk.java.net  Fri May  6 06:48:46 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 6 May 2022 06:48:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v13]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <kw1r-eOnf3xU7xF1-qpb-ddASUTDT60FW0OXSNspvzs=.cd80786d-4dd4-4fbd-bafe-e5786b0d1afd@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3
 - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf
 - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
 - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
 - Merge with jdk-19+20
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/9425ab2b...6d968671

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=12
  Stats: 99456 lines in 1130 files changed: 91188 ins; 3598 del; 4670 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Fri May  6 07:19:47 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 6 May 2022 07:19:47 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v7]
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <JWPDzNDVsGHzicGa_ehpAbUhDR1oNNDGjcBGepPsgnE=.8b1dfaaa-fcb5-47fb-a42c-0004c6b09e39@github.com>

> Hello,
> 
> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
> 
> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
> 
> 
> Greetings
> Raffaello

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Merge branch 'master' into JDK-4511638
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Adapted hashes in ElementStructureTest.java
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Merge branch 'master' into JDK-4511638
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Enhanced intervals in MathUtils.
   Updated references to Schubfach v4.
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Merge branch 'master' into JDK-4511638
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments.
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Merge branch 'master' into JDK-4511638
 - 4511638: Double.toString(double) sometimes produces incorrect results
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Refactored test classes to better match OpenJDK conventions.
   Added tests recommended by Guy Steele and Paul Zimmermann.
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/dd06cc63...a36ff8ac

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

Changes: https://git.openjdk.java.net/jdk/pull/3402/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=06
  Stats: 23938 lines in 16 files changed: 23809 ins; 54 del; 75 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402

PR: https://git.openjdk.java.net/jdk/pull/3402

From mbaesken at openjdk.java.net  Fri May  6 07:36:48 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 6 May 2022 07:36:48 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <HxGEWDrc8r3LwkIXozfaxZf-b9aNcL_v-U39YTua1dY=.d0287a56-ddac-48a0-b4e7-06ab6a81e454@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
 <iMA0pSqzQRdteblNyOe8cqE968h9tbYi23Unx5RkCSA=.3ac8f2a3-c445-42f2-8431-fc942616f3b9@github.com>
 <HxGEWDrc8r3LwkIXozfaxZf-b9aNcL_v-U39YTua1dY=.d0287a56-ddac-48a0-b4e7-06ab6a81e454@github.com>
Message-ID: <txaoJZnuw4c7UhUYYv2kmA4oEaPW2Caju-plJlcE3qM=.e43e196d-2701-4914-a94f-8c608cce8da4@github.com>

On Wed, 4 May 2022 09:08:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Does this mean that not setting _WIN32_WINNT means :any API is allowed" ?

Hi David , I did one more try with my current setup (VS2017 on a Win10 notebook). I did not set _WIN32_WINNT.
My little test program 


#include <windows.h>
#include <stdio.h>

int main() {

#ifdef _WIN32_WINNT
  printf("_WIN32_WINNT is defined .\n");

#if (_WIN32_WINNT == 0x0600)
  printf("Vista API setting\n");
#endif

#if (_WIN32_WINNT == 0x0601)
  printf("Win 7 API setting\n");
#endif

#if (_WIN32_WINNT == 0x0602)
  printf("Win 8 API setting\n");
#endif

#if (_WIN32_WINNT == 0x0603)
  printf("Win 8.1 API setting\n");
#endif

#if (_WIN32_WINNT == 0x0A00)
  printf("Win 10 API setting\n");
#endif

#endif

  return 0;
}


shows me 
_WIN32_WINNT is defined .
Win 10 API setting

So I think with our current compilers in use like VS2017 / VS2019 we allow Win10 APIs   in most of our code except a few places where we set _WIN32_WINNT  and go back to some mixture of older APIs.
Not sure if this is a good thing,  we could break for example Win 8.1/Win2012 compatibility easily this way.

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From duke at openjdk.java.net  Fri May  6 08:29:33 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 6 May 2022 08:29:33 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v8]
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <5mx6jQDLLnWjuJZ-vj0uuyFHtjpGbRafo4nnxjWDYbo=.872d7486-16fd-4b51-90f8-1ec14549559f@github.com>

> Hello,
> 
> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
> 
> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
> 
> 
> Greetings
> Raffaello

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

  4511638: Double.toString(double) sometimes produces incorrect results

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3402/files
  - new: https://git.openjdk.java.net/jdk/pull/3402/files/a36ff8ac..904ba115

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=06-07

  Stats: 389 lines in 5 files changed: 40 ins; 216 del; 133 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402

PR: https://git.openjdk.java.net/jdk/pull/3402

From shade at openjdk.java.net  Fri May  6 08:32:46 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 6 May 2022 08:32:46 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
In-Reply-To: <IClQBci8WY_me9QbqEJc1YmrSDb69SSwbs30vvXk0FE=.1952a7e8-af0d-4c56-a6e3-16459a8026bf@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com>
 <JEybFaDnjzr7ucOpe3QVrZsDGzOYgZaXvEiCfU8-kTs=.089e55ac-7c9d-42db-8cbe-b9f985823387@github.com>
 <IClQBci8WY_me9QbqEJc1YmrSDb69SSwbs30vvXk0FE=.1952a7e8-af0d-4c56-a6e3-16459a8026bf@github.com>
Message-ID: <h0IQAD8PepuXk5NE_ddzyldmrGQHqYYDKRy_KECVo6E=.2476bbfa-0957-46a3-bd99-e0dee1046f35@github.com>

On Thu, 5 May 2022 18:54:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We mailed porters-dev in Sep 2021 to give a heads up that this feature would require porting work so it shouldn't be a surprise. We have been open to including other ports with the initial integration but it was never a goal to have all the ports done in advance of that.

It is understandable to ship the preview feature not implemented on all platforms. It is even understandable to ship the final product feature that breaks some platforms in an clearly understandable way, prompting platform maintainers to implement the agreed-upon, final Java feature. What I am seeing, though, is that just running `java -version` (!) after integrating a *preview feature* is broken!

> Most of the new code in the VM is only used when running with --enable-preview. You'll see several places that test Continuations::enabled(). It should be possible to get these port running without -enable-preview without much effort. The feature has to be implemented to pass all the tests of course.

It is not as clear-cut, unfortunately. I see there are substantial changes in deopt machinery with post-call NOPs -- and there maybe more stuff lurking after that one is implemented -- so it is not as simple as changing `Unimplemented()` to guarding with `Continuations::enabled()`. So this looks to me that the core deopt machinery is affected, whether Loom is enabled or not. Is the impact of that deopt machinery change on the VM stability and VM ports discussed, understood, documented somewhere?

I would have honestly expected those core changes to be heavily conditionalized with either `ifdef`-s, or runtime checks, or both, so that both unimplemented platforms had the old behavior *and* the implemented platforms had a fallback to old behavior if preview feature was broken. The current code is fine for experimental Loom repo, but I firmly believe mainline should have much stronger safety/reliability requirements.

My fear is that an integration like this would wreck JDK 19 release. So my question stands: Are we breaking those platforms? Are we sure the unconditional VM changes are problem-free, implementable everywhere, etc? The answer might be "Yes, we are integrating, let the chips fall where they may", but I also believe that should be the call made by responsible platform/VM architects, who should explicitly weigh in and accept the risk of wide JDK 19 breakage.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From duke at openjdk.java.net  Fri May  6 08:40:40 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 6 May 2022 08:40:40 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v9]
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <9LlMrgbo6bnU1-r2uub4WBFUYSUhzlA12yEzdLbJrF8=.ad11eb59-a133-4323-a67a-5e691f8d96ea@github.com>

> Hello,
> 
> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
> 
> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
> 
> 
> Greetings
> Raffaello

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

  4511638: Double.toString(double) sometimes produces incorrect results

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3402/files
  - new: https://git.openjdk.java.net/jdk/pull/3402/files/904ba115..e7c4bd25

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/3402

From mcimadamore at openjdk.java.net  Fri May  6 08:44:18 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 08:44:18 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v39]
In-Reply-To: <aImM-95p05F3f-XDzASkz3T9U8L_zi0XUTpqmGsyq9o=.5a4ae8f0-35a7-4da1-b1e5-01efcc4d16af@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <gEIYNc5S2KxVCScOlOJcrUp5Fdlkjw1N6qykKYot4Kw=.b692629a-f9f5-45c0-9127-cdb7fdeebe6c@github.com>
 <aImM-95p05F3f-XDzASkz3T9U8L_zi0XUTpqmGsyq9o=.5a4ae8f0-35a7-4da1-b1e5-01efcc4d16af@github.com>
Message-ID: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com>

On Thu, 5 May 2022 21:28:32 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
>>   * Tweak restricted method check to work when there's no caller class
>
> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 161:
> 
>> 159:                 ClassLoader.getSystemClassLoader();
>> 160:         MemorySession loaderSession = (loader == null) ?
>> 161:                 MemorySession.global() : // boot loader never goes away
> 
> The other built-in class loaders (`ClassLoaders::appClassLoader` and `ClassLoaders::platformClassLoader` are both instance of `BuiltinClassLoader`) will never be unloaded.   Should they use the globel memory session?

good idea

> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120:
> 
>> 118:         // if there is no caller class, act as if the call came from an unnamed module
>> 119:         Module module = currentClass != null ?
>> 120:                 currentClass.getModule() : Holder.FALLBACK_MODULE;
> 
> This can be simplified to:
> 
> Module module = currentClass != null ?
>                currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule();
> 
> 
> No need to have the Holder class.

gah! I missed that :-)

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From abimpoudis at openjdk.java.net  Fri May  6 09:29:47 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 6 May 2022 09:29:47 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <ARuPq5vlo0dKLhaeZUYa30wcFd7GDZp-twt8cu4B1Zg=.436547c2-b52f-4c68-89bf-468416a99a2a@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <ARuPq5vlo0dKLhaeZUYa30wcFd7GDZp-twt8cu4B1Zg=.436547c2-b52f-4c68-89bf-468416a99a2a@github.com>
Message-ID: <Iy47suZU3gubfJfa-JTLMTBg8-UW8gBvuCwCf7aD6E0=.05749c17-7dc3-44b4-931e-54de051e93ff@github.com>

On Thu, 5 May 2022 11:57:34 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 783:
> 
>> 781:             }
>> 782:             for (Entry<Symbol, List<JCDeconstructionPattern>> e : categorizedDeconstructionPatterns.entrySet()) {
>> 783:                 if (coversDeconstructionStartingFromComponent(pos, targetType, e.getValue(), 0)) {
> 
> Here, the result of `e.getValue` is a reversed list of the observed patterns. 
> 
> For the switch below,
> 
> 
> switch (r) {
>             case R(A a, A b) -> 1;
>             case R(A a, B b) -> 2;
>             case R(B a, A b) -> 3;
>             case R(B a, B b) -> 4;
> }
> 
> 
> The 0th element of that list is the `R(B a, B b)` pattern, the 1st the `R(B a, A b)`. I am 99% sure that this is not a problem but I am pointing it out regardless, in case there is any underlying danger to that.

Order doesn't matter. I triple checked.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From alanb at openjdk.java.net  Fri May  6 09:51:20 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 6 May 2022 09:51:20 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v13]
In-Reply-To: <kw1r-eOnf3xU7xF1-qpb-ddASUTDT60FW0OXSNspvzs=.cd80786d-4dd4-4fbd-bafe-e5786b0d1afd@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
 <kw1r-eOnf3xU7xF1-qpb-ddASUTDT60FW0OXSNspvzs=.cd80786d-4dd4-4fbd-bafe-e5786b0d1afd@github.com>
Message-ID: <apoi69wlbi5W27w85tRBUvBvU0od_yc6bHjTJRVmfZ0=.06215232-4cbb-43fe-bd43-4a0fc17a73e4@github.com>

On Fri, 6 May 2022 06:48:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 425: Virtual Threads (Preview).
>> 
>> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
>> 
>> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
>> 
>> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
>> 
>> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
>> 
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
>> 
>> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3
>  - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf
>  - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
>  - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
>  - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
>  - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
>  - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
>  - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
>  - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec
>  - Merge with jdk-19+20
>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/9425ab2b...6d968671

> It is understandable to ship the preview feature not implemented on all platforms. It is even understandable to ship the final product feature that breaks some platforms in an clearly understandable way, prompting platform maintainers to implement the agreed-upon, final Java feature. What I am seeing, though, is that just running `java -version` (!) after integrating a _preview feature_ is broken!

Preview features need to be implemented by a port before it can be released. For JDK 19 this means that the maintainers of ports will have work to do for both JEP 424 and JEP 425 (ifdef is not an option).

I think the issue that are concerned about is the interim period between the JEP 425 integration and the port/implementation of this feature to other architectures. I think the answer is that it will vary. It may be that some port maintainers decide to do something very short term so they can run without --enable-preview and buy time before they do the port/implementation for JDK 19. Good progress has been reported on at least ppc64le port and maybe that port be ready before others. So yes, some ports may crash until they receive attention, others (like zero) should be able to run tests that don't use --enable-preview. I've no doubt there will be a flurry of changes post integration.

The motivation for Continuations::enabled() was to reduce risk and disable a lot of the new code by default. The motivation wasn't porting but it may be helpful during the interim period. That is probably a topic for loom-dev rather here.

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From dholmes at openjdk.java.net  Fri May  6 09:52:47 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 6 May 2022 09:52:47 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
Message-ID: <aI6o7r7S3F904PQ5ZT9cMfCujg0b_9XUdnRLByaw338=.b3974da8-1f18-49a1-93dc-426d154a96a6@github.com>

On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust API level to Windows 8 for security.cpp and do some cleanup

This seems okay to me in this form.

I agree that explicitly setting this is better than unknowingly using API's that might not be available on supported platforms.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8428

From mbaesken at openjdk.java.net  Fri May  6 09:57:47 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 6 May 2022 09:57:47 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
Message-ID: <W8o03kcDfgXlw62W0zngVRhG89m2e1m_XMiH8CkFQFk=.9a486a43-c496-4edc-8a01-70c842f002fc@github.com>

On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust API level to Windows 8 for security.cpp and do some cleanup

Hi David, thanks for the review !

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From ngasson at openjdk.java.net  Fri May  6 10:24:41 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 6 May 2022 10:24:41 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v2]
In-Reply-To: <MCeN_ZJLMC5Ym1gSkXfGzz4PaSD9uN18tv67UGEtVYE=.1214b583-9d8f-4982-915a-088dc432bc3e@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <MCeN_ZJLMC5Ym1gSkXfGzz4PaSD9uN18tv67UGEtVYE=.1214b583-9d8f-4982-915a-088dc432bc3e@github.com>
Message-ID: <DylaohMJwpgdQPexALDuqt8cvpGPXuKy80DZoiTlJ-w=.a500e837-1a01-4f53-bc6b-a80216e08ed4@github.com>

On Thu, 5 May 2022 05:47:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - 8284960: Correcting a typo.
>  - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: AARCH64 backend changes.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Integration of JEP 426: Vector API (Fourth Incubator)

`cpu/aarch64` changes look good.

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

Marked as reviewed by ngasson (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8425

From jlahoda at openjdk.java.net  Fri May  6 10:54:44 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 10:54:44 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <ff8zs0KPz1lnUAXZnOLmgOV29nrMku68gCzcXx22cfk=.e3013590-1330-45f9-9c8e-d39a1784aeda@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
 <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>
 <2GavSjSE5nlrTyB3jqq-MfzgrPPk61-alJ5lr1NNXMw=.87eaf812-dffb-4d45-82e5-9af4dd1552ce@github.com>
 <ff8zs0KPz1lnUAXZnOLmgOV29nrMku68gCzcXx22cfk=.e3013590-1330-45f9-9c8e-d39a1784aeda@github.com>
Message-ID: <EAuN_I-WQ69znIV0H_SNEN9xHHo77oVR-fUhVC32OUU=.0ee69407-f82e-4973-999d-5298acdcea97@github.com>

On Thu, 5 May 2022 15:17:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> You are right. It is the ii) which iteratively checks the component pattern list L.
>
> I now believe that the check is needed to properly classify patterns based on the type of the i-th component. That said, not sure this should be a subtyping check, or a type equality

A good question. Consider code like:

    private void test(R r) {
        switch (r) {
            case R(A a, A v) -> {}
            case R(B b, A v) -> {}
            case R(I i, B v) -> {}
        }
    }
    final class A implements I {}
    sealed interface I permits A, B {}
    final class B implements I {}
    record R(I i1, I i2) {}


The switch is exhaustive - all the possible combinations are covered. When checking the first component, the code will categorize the patterns like:

A -> R(A a, A v), R(I i, B v)
B -> R(B b, A v), R(I i, B v)
I   -> R(I i, B v)

this categorization is done using the subtype check, so that `R(I i, B v)` will appear in the list for `A`. When checking the second component, the possibility for `I` is not exhaustive (does not cover `A` in the second component), but the possibilities for `A` and `B` are exhaustive, and they together cover `I`.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From redestad at openjdk.java.net  Fri May  6 11:39:03 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 6 May 2022 11:39:03 GMT
Subject: RFR: 8286298: Remove unused methods in sun.invoke.util.VerifyType
Message-ID: <hm_DCon8SD1b9B3sGDnoRHndjsIU5QKMa2czmHBxRlU=.6a79e0ab-9199-42a8-a69d-183fbfa92cb3@github.com>

A few untested and unused methods in `VerifyType` which can be removed. (Possibly used by native JSR 292 implementations in JDK 7).

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

Commit messages:
 - Remove unused methods in sun.invoke.util.VerifyType

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

PR: https://git.openjdk.java.net/jdk/pull/8570

From mcimadamore at openjdk.java.net  Fri May  6 11:47:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 11:47:46 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <EAuN_I-WQ69znIV0H_SNEN9xHHo77oVR-fUhVC32OUU=.0ee69407-f82e-4973-999d-5298acdcea97@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <NFlkFi9wse87_Zh8kaQ6z4vFtgcKcbZIfgILqg_nuqU=.2dd5ecc8-7c42-4773-a798-a7e51e4a4bc2@github.com>
 <gcVqv_hBTkwYvrrmr3eQ3shlJQ0bkAD0esew-pR7DvQ=.c3d92f14-3bf4-41a1-8d05-d02121030be1@github.com>
 <2GavSjSE5nlrTyB3jqq-MfzgrPPk61-alJ5lr1NNXMw=.87eaf812-dffb-4d45-82e5-9af4dd1552ce@github.com>
 <ff8zs0KPz1lnUAXZnOLmgOV29nrMku68gCzcXx22cfk=.e3013590-1330-45f9-9c8e-d39a1784aeda@github.com>
 <EAuN_I-WQ69znIV0H_SNEN9xHHo77oVR-fUhVC32OUU=.0ee69407-f82e-4973-999d-5298acdcea97@github.com>
Message-ID: <rfSLRnkD06hQsseSOVLaUAyqYVbdd4XeGJlsgCSucj4=.6bfca844-1270-4740-93fb-9a074f83c46c@github.com>

On Fri, 6 May 2022 10:51:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I now believe that the check is needed to properly classify patterns based on the type of the i-th component. That said, not sure this should be a subtyping check, or a type equality
>
> A good question. Consider code like:
> 
>     private void test(R r) {
>         switch (r) {
>             case R(A a, A v) -> {}
>             case R(B b, A v) -> {}
>             case R(I i, B v) -> {}
>         }
>     }
>     final class A implements I {}
>     sealed interface I permits A, B {}
>     final class B implements I {}
>     record R(I i1, I i2) {}
> 
> 
> The switch is exhaustive - all the possible combinations are covered. When checking the first component, the code will categorize the patterns like:
> 
> A -> R(A a, A v), R(I i, B v)
> B -> R(B b, A v), R(I i, B v)
> I   -> R(I i, B v)
> 
> this categorization is done using the subtype check, so that `R(I i, B v)` will appear in the list for `A`. When checking the second component, the possibility for `I` is not exhaustive (does not cover `A` in the second component), but the possibilities for `A` and `B` are exhaustive, and they together cover `I`.

Ah - makes sense of course - I "just" needed a more convoluted example :-)

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mcimadamore at openjdk.java.net  Fri May  6 11:51:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 11:51:46 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v40]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <UpO4v4kC3b9lEGmVeW3AUc3-LsV3p4iwtIOdKQXigXg=.af6c09ea-2890-41fa-bb18-82ad9938b54b@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

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

  Add tests for loaderLookup/restricted method corner cases

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/4d24ffa9..b71c4e93

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=39
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=38-39

  Stats: 248 lines in 10 files changed: 239 ins; 4 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Fri May  6 11:51:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 11:51:46 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v39]
In-Reply-To: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <gEIYNc5S2KxVCScOlOJcrUp5Fdlkjw1N6qykKYot4Kw=.b692629a-f9f5-45c0-9127-cdb7fdeebe6c@github.com>
 <aImM-95p05F3f-XDzASkz3T9U8L_zi0XUTpqmGsyq9o=.5a4ae8f0-35a7-4da1-b1e5-01efcc4d16af@github.com>
 <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com>
Message-ID: <Odtl0HHxQJgJ-iYs-nn7IkIYEv8pSCCh_I-PvT1-__U=.692f3729-cdb6-4eba-9e89-c2caf2fcaf63@github.com>

On Fri, 6 May 2022 08:42:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120:
>> 
>>> 118:         // if there is no caller class, act as if the call came from an unnamed module
>>> 119:         Module module = currentClass != null ?
>>> 120:                 currentClass.getModule() : Holder.FALLBACK_MODULE;
>> 
>> This can be simplified to:
>> 
>> Module module = currentClass != null ?
>>                currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule();
>> 
>> 
>> No need to have the Holder class.
>
> gah! I missed that :-)

I've addressed these comments (thanks!) and also added some tests for these corner cases.

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From jlahoda at openjdk.java.net  Fri May  6 12:01:00 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 12:01:00 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <aXWInt5Fx8rtPdhD0B4IGHpEeXf8azyT99uPFsmZUpA=.1d0e2315-7c53-4d63-8f07-cb1460513d67@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <nczDm8w9L3XQP6rAGi3AaNssM7hwD2vsisD11luyF30=.cc1afbda-df3e-4cfc-873c-d2aa34125616@github.com>
 <aXWInt5Fx8rtPdhD0B4IGHpEeXf8azyT99uPFsmZUpA=.1d0e2315-7c53-4d63-8f07-cb1460513d67@github.com>
Message-ID: <iN1xCC5z772qtp9-mKoveY5nu8HEbM27pF0ErqM8Mf0=.3c8971cf-fa27-4e0b-830f-8c6492484f8c@github.com>

On Wed, 4 May 2022 10:03:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4180:
>> 
>>> 4178:             type = attribTree(tree.var.vartype, env, varInfo);
>>> 4179:         } else {
>>> 4180:             type = resultInfo.pt;
>> 
>> Looks good - infers the binging var type from the record component being processed. If not in a record, then I suspect resultInfo.pt is just the target expression type (e.g. var in toplevel environment).
>
> That said, I'm not sure how this connects with `instanceof`. This patch doesn't seem to alter `visitTypeTest`. In the current code I can see this:
> 
> if (tree.pattern.getTag() == BINDINGPATTERN ||
>            tree.pattern.getTag() == PARENTHESIZEDPATTERN) {
>            attribTree(tree.pattern, env, unknownExprInfo);
>            ...
>            
> 
> This seems wrong for two reasons:
> 
> * it doesn't take into account the new pattern tag
> * it uses an "unknown" result info when attributing, meaning that any toplevel `var` pattern will not be attributed correctly
> 
> But we seem to have tests covering record patterns and instanceof. so I'm wondering if I'm missing some code update?

Some of the handling inside this ifs is only needed for type test and parenthesized patterns (as record patterns are never unconditional (total)). I have an upcoming patch that should improve the tests here, however.

For `var` - the specification does not allow `var` at the top level (14.30.1, "The LocalVariableType in a top-level type pattern denotes a reference type (and furthermore is not var)."). In my upcoming patch, I am adding a test to ensure meaningful behavior for top-level type test patterns with `var`.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From erikj at openjdk.java.net  Fri May  6 12:47:41 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 6 May 2022 12:47:41 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
Message-ID: <5t5qsNQ4XMMB_1ACFCDIKGj1BxBnsmAAq5d4C5z3yQU=.c1c2bb90-57dc-4754-a2cd-56b0e5d58843@github.com>

On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust API level to Windows 8 for security.cpp and do some cleanup

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From lbourges at openjdk.java.net  Fri May  6 13:42:01 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 6 May 2022 13:42:01 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <87LGXiMawP751-7D5F7u7-1EW_iOS028crS4EW-Wefs=.ef4a1bbd-d7f5-4729-83cc-ad924c267c1f@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

I am improving test code (jmh + robust estimators) to have more robust results on small arrays (20 - 1000).
I do hope having new results within 1 or 2 weeks.

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

PR: https://git.openjdk.java.net/jdk/pull/3938

From jlahoda at openjdk.java.net  Fri May  6 14:09:24 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 14:09:24 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

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

  Reflecting review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8516/files
  - new: https://git.openjdk.java.net/jdk/pull/8516/files/56020b0b..90b37c3a

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

  Stats: 193 lines in 18 files changed: 67 ins; 19 del; 107 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From itakiguchi at openjdk.java.net  Fri May  6 14:23:00 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 6 May 2022 14:23:00 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v5]
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <Mm6ZoGWlMgP8OqfoGZ5cu0jCwR24t0E-4j6iFxW5nqI=.7dabc177-9e05-4033-b366-f8c29357ecda@github.com>

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

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

  8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8378/files
  - new: https://git.openjdk.java.net/jdk/pull/8378/files/84e6d639..5bd8492f

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

  Stats: 103 lines in 4 files changed: 39 ins; 39 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8378/head:pull/8378

PR: https://git.openjdk.java.net/jdk/pull/8378

From abimpoudis at openjdk.java.net  Fri May  6 14:32:54 2022
From: abimpoudis at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 6 May 2022 14:32:54 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
Message-ID: <2fBRfV4OxKk_OYkO8lKU7bEyHi8lrnen1ZOsnI80BFY=.80a15060-7bcf-434a-9e3a-c2e008a110f9@github.com>

On Fri, 6 May 2022 14:09:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

>From the JLS specdiff

> If the type R names a generic record class then it is a compile-time error if R is not a parameterized type.

The following snippet raises a `MatchException`. Shouldn't it be a compile-time error?


        Box<String> r = new Box<>(null);

        switch (r) {
            case Box(String s):
                System.out.println("match");
        }

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From itakiguchi at openjdk.java.net  Fri May  6 14:33:00 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 6 May 2022 14:33:00 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
 <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
Message-ID: <PADPwCNkTqUSHcxMWYR9QNlv36SmNXPv6Ij05YKayc0=.73cdc10c-d254-4478-9b5f-54911b94d148@github.com>

On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> Can you clarify the use of different charset properties for the ProcessEnvironment vs the CommandLine strings?
> 
> They are used to decode or encode strings in the APIs to native functions respectively.
> If I understand `native.encoding` was introduced to reflect the default encoding of file contents, while `sun.jnu.encoding` is used to encode filenames.
> 
> I think I would have expected to see `sun.jnu.encoding` to be used in all contexts when encoding/decoding strings to the native representations.  (Assuming its not required for backward compatibility).

Hello @RogerRiggs and @naotoj .
I put sun.jnu.encoding related code into s`StaticProperty.java`.
Could you review the files again including javadoc comment ?

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From itakiguchi at openjdk.java.net  Fri May  6 14:33:06 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 6 May 2022 14:33:06 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v4]
In-Reply-To: <tRSCLtwhcT3K3Cdy8VZC4qQGS33-Uss4jEUZNlfjeHw=.4a38432f-8fb3-4ad3-9cb4-906f2ceea673@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <1dZ6o94-xt1oOEevAAO3uYDQrjStchH0FfrHi88V1OE=.bbc63a8f-7959-46fa-ad9c-292c09e80ae5@github.com>
 <tRSCLtwhcT3K3Cdy8VZC4qQGS33-Uss4jEUZNlfjeHw=.4a38432f-8fb3-4ad3-9cb4-906f2ceea673@github.com>
Message-ID: <cttQS8FpqHG48GDEtWDSZq648eR6WwRNgDIWORSxawE=.75f0b3e5-5c72-4bc6-80e1-92861ed65d0a@github.com>

On Thu, 5 May 2022 01:34:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> test/jdk/java/lang/System/i18nEnvArg.java line 70:
> 
>> 68:             Map<String, String> environ = pb.environment();
>> 69:             environ.clear();
>> 70:             environ.put("LANG", "ja_JP.eucjp");
> 
> There are many duplicate pieces of code here and in the `else` block below. Can you simplify this `if` statement more?

Modified.
But I'm not sure, it's expected one.

> test/jdk/java/lang/System/i18nEnvArg.java line 110:
> 
>> 108:             String s = System.getenv(EUC_JP_TEXT);
>> 109:             ByteArrayOutputStream baos = new ByteArrayOutputStream();
>> 110:             PrintStream ps = new PrintStream(baos);
> 
> Can utilize try-with-resources pattern.

Use `shouldNotContain()` to find the error message.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From duke at openjdk.java.net  Fri May  6 14:33:50 2022
From: duke at openjdk.java.net (Shruthi)
Date: Fri, 6 May 2022 14:33:50 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v3]
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <q4ErCHNEb_FnyyngTzuiJudZmyAc4EiPCgOZw7Eg5_Y=.67ef26dc-94eb-4aed-8858-41174aac8148@github.com>

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

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

  Replace the ER_RTF_NOT_SUPPORTED_XRTREEFRAGSELECTWRAPPER key in XPATHErrorResources language files

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8318/files
  - new: https://git.openjdk.java.net/jdk/pull/8318/files/d53ca37e..c294a150

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

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From ihse at openjdk.java.net  Fri May  6 14:38:50 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 6 May 2022 14:38:50 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
Message-ID: <wmeNcJMpj3d3F7at-qvo9uRgIF4LToKHDNoKklOBLVg=.c6bcf46f-6680-4338-9fda-7f5e88398e23@github.com>

On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust API level to Windows 8 for security.cpp and do some cleanup

Looks good, thanks for doing this cleanup.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8428

From mcimadamore at openjdk.java.net  Fri May  6 14:46:58 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 14:46:58 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
Message-ID: <BRVCNwq7xvWl2AwuqeynSn5BfSc3G7LTaXoee3r3neQ=.90f9863d-7651-405a-b2b4-10cfd75429dd@github.com>

On Fri, 6 May 2022 14:09:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

Looks good

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 752:

> 750:                                            Iterable<? extends JCCaseLabel> labels) {
> 751:             Set<Symbol> coveredSymbols = new HashSet<>();
> 752:             Map<Symbol, List<JCRecordPattern>> deconstructionPatternsBySymbol = new HashMap<>();

since you seem to have settled on "recordPattern" for implementation names - you can probably revisit some of these names to say "record" instead of "deconstruction".

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 801:

> 799:             //i.e. represent all possible combinations.
> 800:             //This is done by categorizing the patterns based on the type covered by the given
> 801:             //starting component.

Example needed here. For instance (I discussed this with @biboudis):


record Outer(R r) { };
sealed interface I { };
class A implements I { };
class B implements I { };
sealed interface R { };
record Foo(I i) implements R { }
record Bar(I i) implements R { }

switch (o) {
   case Outer(Foo(A), Foo(A)):
   case Outer(Foo(B), Foo(B)):
   case Outer(Foo(A), Foo(B)):
   case Outer(Foo(B), Foo(A)):
   case Outer(Bar(A), Bar(A)):
   case Outer(Bar(B), Bar(B)):
   case Outer(Bar(A), Bar(B)):
   case Outer(Bar(B), Bar(A)):
}


Which generates two sets:


   case Outer(Foo(A), Foo(A)):
   case Outer(Foo(B), Foo(B)):
   case Outer(Foo(A), Foo(B)):
   case Outer(Foo(B), Foo(A)):


And


   case Outer(Bar(A), Bar(A)):
   case Outer(Bar(B), Bar(B)):
   case Outer(Bar(A), Bar(B)):
   case Outer(Bar(B), Bar(A)):


Sorry for being pedantic - this code is tricky and I'm worried we'll all forget exactly how it works in 2 months :-)

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1014:

> 1012:                         pattern = parsePattern(patternPos, mods, type, false);
> 1013:                     } else if (token.kind == LPAREN) {
> 1014:                         pattern = parsePattern(patternPos, mods, type, false);

Nice!

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

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8516

From duke at openjdk.java.net  Fri May  6 15:02:07 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 6 May 2022 15:02:07 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v3]
In-Reply-To: <q4ErCHNEb_FnyyngTzuiJudZmyAc4EiPCgOZw7Eg5_Y=.67ef26dc-94eb-4aed-8858-41174aac8148@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <q4ErCHNEb_FnyyngTzuiJudZmyAc4EiPCgOZw7Eg5_Y=.67ef26dc-94eb-4aed-8858-41174aac8148@github.com>
Message-ID: <hQzqy_VsSU9hqDCjQ66gzEk3rbewhOdGy3l42m1LFHw=.c72cf7ff-5cd9-455d-b974-cefb28a3b40e@github.com>

On Fri, 6 May 2022 14:33:50 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace the ER_RTF_NOT_SUPPORTED_XRTREEFRAGSELECTWRAPPER key in XPATHErrorResources language files

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

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java line 599:

> 597: 
> 598:   { ER_ASNODEITERATOR_NOT_SUPPORTED_XRTREEFRAGSELECTWRAPPER,
> 599:        "asNodeIterator() not supported by XRTreeFragSelectWrapper"},

For this key, please review places where the old key was used to find places where the new key was intended. I believe [this line](https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/sun/org/apache/xpath/internal/objects/XRTreeFragSelectWrapper.java#L155) is an example.

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Fri May  6 15:02:09 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 6 May 2022 15:02:09 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v2]
In-Reply-To: <KgMTSXgQpF3NOHQx8y9rxMKafJMWGjvd4MPo2irnzU0=.63d20ba0-1c52-4e3d-b277-15be857a9efc@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <y0SfoETM89xliE9cpp9chn_ymb7fGSHSAyEnSc_ukWM=.92983e87-86b8-404c-bca8-501d5bd741eb@github.com>
 <KgMTSXgQpF3NOHQx8y9rxMKafJMWGjvd4MPo2irnzU0=.63d20ba0-1c52-4e3d-b277-15be857a9efc@github.com>
Message-ID: <0wUIvERFKuugcFNsU7ODNwfBdEH7QHGxurQFMe4MHRE=.95143a4a-e7d2-455d-b22b-0b8d0c8df370@github.com>

On Mon, 2 May 2022 07:39:39 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating last modified tag and XRTreeFragSelectWrapper.java
>
> `/integrate`

LGTM. Nicely done @shruacha1234

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Fri May  6 15:02:10 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 6 May 2022 15:02:10 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v3]
In-Reply-To: <hQzqy_VsSU9hqDCjQ66gzEk3rbewhOdGy3l42m1LFHw=.c72cf7ff-5cd9-455d-b974-cefb28a3b40e@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <q4ErCHNEb_FnyyngTzuiJudZmyAc4EiPCgOZw7Eg5_Y=.67ef26dc-94eb-4aed-8858-41174aac8148@github.com>
 <hQzqy_VsSU9hqDCjQ66gzEk3rbewhOdGy3l42m1LFHw=.c72cf7ff-5cd9-455d-b974-cefb28a3b40e@github.com>
Message-ID: <nxOZVinGLhtFIpqEJLaj5oS8NHYu0YMHeZ84kKiacBw=.9ed2a8d3-ace8-4cfe-8e19-39e368eff01b@github.com>

On Wed, 20 Apr 2022 15:48:54 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace the ER_RTF_NOT_SUPPORTED_XRTREEFRAGSELECTWRAPPER key in XPATHErrorResources language files
>
> src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java line 599:
> 
>> 597: 
>> 598:   { ER_ASNODEITERATOR_NOT_SUPPORTED_XRTREEFRAGSELECTWRAPPER,
>> 599:        "asNodeIterator() not supported by XRTreeFragSelectWrapper"},
> 
> For this key, please review places where the old key was used to find places where the new key was intended. I believe [this line](https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/sun/org/apache/xpath/internal/objects/XRTreeFragSelectWrapper.java#L155) is an example.

[Here](https://github.com/openjdk/jdk/blob/64225e19995e81d2e836ce84befea1a01bb6c860/src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java#L595) is another usage where the other key is intended. I expect you will find similar references in at least some of the other translation files.

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From psandoz at openjdk.java.net  Fri May  6 15:02:53 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 6 May 2022 15:02:53 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <OGo9aUs8yLmsxC1eoalXA3G6yC7U9aEVtkUqrussqCc=.3385b881-7225-4552-aa5a-47a30968afdd@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <ZU_NGFdXj1afua9vWK7R1W2uHis87SnXhPUegbYqcYw=.50877d5e-7003-4408-8dbd-20ca89ccc442@github.com>
 <PSsn8b0tFvdfFfNw1s0EqBdxgqv0BTL3smIABpPRhIU=.98db7e11-6220-401b-b03a-abc6380d622d@github.com>
 <lgRc3_J4AFK0NPUD0_EuiAwUWj_d4Ka6FzXH3npBARY=.21cf89ef-f605-4f40-b59f-7c57a1faf1d4@github.com>
 <OGo9aUs8yLmsxC1eoalXA3G6yC7U9aEVtkUqrussqCc=.3385b881-7225-4552-aa5a-47a30968afdd@github.com>
Message-ID: <RNdtDRHmdauB0JDZVxiM_GcykLet6ApqTm46SYgBGhQ=.e0c46e0c-7811-4759-b4a0-e2b941730fe9@github.com>

On Fri, 6 May 2022 04:49:39 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> offset is long so uses two argument slots (5 and 6). 
>> mask is argument (7).
>> offsetInRange is argument(8).
>
> Make sense! Thanks for the explanation!

Doh! of course. This is not the first and will not be the last time i get caught out by the 2-slot requirement.
It may be useful to do this:

Node* mask_arg = is_store ? argument(8) : argument(7);

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From dl at openjdk.java.net  Fri May  6 15:12:12 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Fri, 6 May 2022 15:12:12 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins
Message-ID: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>

Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool

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

Commit messages:
 - Override close as explicit no-op for common pool

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From bpb at openjdk.java.net  Fri May  6 15:39:51 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 6 May 2022 15:39:51 GMT
Subject: RFR: 8286298: Remove unused methods in sun.invoke.util.VerifyType
In-Reply-To: <hm_DCon8SD1b9B3sGDnoRHndjsIU5QKMa2czmHBxRlU=.6a79e0ab-9199-42a8-a69d-183fbfa92cb3@github.com>
References: <hm_DCon8SD1b9B3sGDnoRHndjsIU5QKMa2czmHBxRlU=.6a79e0ab-9199-42a8-a69d-183fbfa92cb3@github.com>
Message-ID: <5gj9qdIftwsKBdoH31GmSPlpQGcsfh97KRsuRfaox6Y=.f96f0ade-b63d-4e86-a237-f73fd4dd1dc4@github.com>

On Fri, 6 May 2022 11:32:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few untested and unused methods in `VerifyType` which can be removed. (Possibly used by native JSR 292 implementations in JDK 7).

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8570

From duke at openjdk.java.net  Fri May  6 15:45:08 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 6 May 2022 15:45:08 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v9]
In-Reply-To: <9LlMrgbo6bnU1-r2uub4WBFUYSUhzlA12yEzdLbJrF8=.ad11eb59-a133-4323-a67a-5e691f8d96ea@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <9LlMrgbo6bnU1-r2uub4WBFUYSUhzlA12yEzdLbJrF8=.ad11eb59-a133-4323-a67a-5e691f8d96ea@github.com>
Message-ID: <fhskU33lLFJJolLDBz9lW5SJV0tPBbkVQYzvP27SXw8=.3ea2b285-3ac3-41c5-a127-45f1ca97e052@github.com>

On Fri, 6 May 2022 08:40:40 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

Match the CSR
Updated Schubfach writing URL

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

PR: https://git.openjdk.java.net/jdk/pull/3402

From gbierman at openjdk.java.net  Fri May  6 15:47:51 2022
From: gbierman at openjdk.java.net (Gavin Bierman)
Date: Fri, 6 May 2022 15:47:51 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
Message-ID: <yfzxxHdWskcWrJOxDBMMeSXV-24cL3E-kdvQ71FwArA=.b1c9b7f7-5fcd-4462-ab4d-137364a9bafd@github.com>

On Fri, 6 May 2022 14:09:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

> From the JLS specdiff
> 
> > If the type R names a generic record class then it is a compile-time error if R is not a parameterized type.
> 
> The following snippet raises a `MatchException`. Shouldn't it be a compile-time error?
> 
> ```
>         Box<String> r = new Box<>(null);
> 
>         switch (r) {
>             case Box(String s):
>                 System.out.println("match");
>         }
> ```
> 
> If this is Ok and my understanding is wrong, then why that raises an exception at all? I can make it work (as an unconditional) if I define the Box as `record Box<T extends String>` and now I am confused...
> 
> ping @GavinBierman @lahodaj

A couple of issues here. (1) This should be a compile-time error. (2) upon investigation I think there is a bug with the pattern matching code, because the compiler is currently saying that the pattern match here: `Box<String> bs = new Box<>(null); if (bs instanceof Box<String>(String s)) { System.out.println("match!"); }` does not succeed. (It should do). The `MatchException` you are seeing is that the exhaustive pattern switch has no matching label (if you put in a default, you don't get the exception).

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From duke at openjdk.java.net  Fri May  6 15:49:26 2022
From: duke at openjdk.java.net (lennartfricke)
Date: Fri, 6 May 2022 15:49:26 GMT
Subject: RFR: 8286163: micro-optimize Instant.plusSeconds
Message-ID: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>

Provide micro-benchmark for comparison

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

Commit messages:
 - 8286163: micro-optimize Instant.plusSeconds

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

PR: https://git.openjdk.java.net/jdk/pull/8542

From robilad at openjdk.java.net  Fri May  6 15:49:26 2022
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Fri, 6 May 2022 15:49:26 GMT
Subject: RFR: 8286163: micro-optimize Instant.plusSeconds
In-Reply-To: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
References: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
Message-ID: <ZgK4_06kMXbOac9poByAqCDd7hMkGAID5LpEeGVubXU=.e7117020-dbbd-4b3d-b5e9-126168080aee@github.com>

On Wed, 4 May 2022 20:27:04 GMT, lennartfricke <duke at openjdk.java.net> wrote:

> Provide micro-benchmark for comparison

Hi, please send an e-Mail to Dalibor.Topic at oracle.com so that I can mark your account as verified.

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

PR: https://git.openjdk.java.net/jdk/pull/8542

From duke at openjdk.java.net  Fri May  6 16:00:59 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 6 May 2022 16:00:59 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v40]
In-Reply-To: <UpO4v4kC3b9lEGmVeW3AUc3-LsV3p4iwtIOdKQXigXg=.af6c09ea-2890-41fa-bb18-82ad9938b54b@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <UpO4v4kC3b9lEGmVeW3AUc3-LsV3p4iwtIOdKQXigXg=.af6c09ea-2890-41fa-bb18-82ad9938b54b@github.com>
Message-ID: <zVq5gxbr2gaHM7fXVDtI9Fih0pZQl9GyREQ4MsbIdYg=.e995c287-2a11-4a88-8284-f8c215c80ca6@github.com>

On Fri, 6 May 2022 11:51:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add tests for loaderLookup/restricted method corner cases

src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 116:

> 114:         // if there is no caller class, act as if the call came from unnamed module of system class loader
> 115:         Module module = currentClass != null ?
> 116:                 currentClass.getModule() : ClassLoader.getSystemClassLoader().getUnnamedModule();

**Nit:** maybe?add a?line?break
Suggestion:

                currentClass.getModule() :
                ClassLoader.getSystemClassLoader().getUnnamedModule();

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From duke at openjdk.java.net  Fri May  6 16:04:59 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 6 May 2022 16:04:59 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v4]
In-Reply-To: <8HuAzza3YiN-q1ffL_7BeVmxBYEavXgqNgPSaWUb1Mk=.dc42ee03-b285-47fc-b9cb-de364f4960fd@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
 <ExSU35YKEIy5tpdY15m90ooSlu1XJ44KXK4drfOlA5Y=.831108e2-fdcf-45ba-a2d1-99a9b082e43f@github.com>
 <8HuAzza3YiN-q1ffL_7BeVmxBYEavXgqNgPSaWUb1Mk=.dc42ee03-b285-47fc-b9cb-de364f4960fd@github.com>
Message-ID: <JoukFuVcGjtqu31HqgcIctScICDhdsN21R6jjv0IZLw=.06b45bea-8998-4730-80b9-7213e4d02b0f@github.com>

On Fri, 6 May 2022 06:39:59 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> > It would be nice if such a test could be written, but as it stands I think that `Wrappers.java` test is too simplistic.
> 
> Would adding `Wrappers.java` a method-name white-list mechanism suitable in this situation?

It?should really?be a?method?name and?type whitelist.

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From redestad at openjdk.java.net  Fri May  6 16:08:50 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 6 May 2022 16:08:50 GMT
Subject: RFR: 8286163: micro-optimize Instant.plusSeconds
In-Reply-To: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
References: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
Message-ID: <OrRVYYNFTrliqqUCkQsf0w2uLFqrqFU5fopxG0gXyhI=.f6e226e4-d2e7-46ad-82db-0539f3ddef8c@github.com>

On Wed, 4 May 2022 20:27:04 GMT, lennartfricke <duke at openjdk.java.net> wrote:

> Provide micro-benchmark for comparison

Hi, thanks for the contribution! 

How big a speed-up are you observing? 

Keeping the optimization in `plusSeconds` rather than moving it to `plus(long, long)` means expressions like `instant.plusMillis(1000)` won't be helped, but such expressions might be rarely helped anyway so what you have might be better overall since it doesn't add a branch to the common code.

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

PR: https://git.openjdk.java.net/jdk/pull/8542

From naoto at openjdk.java.net  Fri May  6 16:13:49 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 May 2022 16:13:49 GMT
Subject: Integrated: 8286154: Fix 3rd party notices in test files
In-Reply-To: <hLwfE37__3lWiBpqF2v68idqQMNcka-NQFyiGoDVdo8=.63d53f88-33d7-4468-b032-51984746ff4a@github.com>
References: <hLwfE37__3lWiBpqF2v68idqQMNcka-NQFyiGoDVdo8=.63d53f88-33d7-4468-b032-51984746ff4a@github.com>
Message-ID: <00rxCVhvQQ_RazJdH1trLX2H8NLddhywIKuQ_eVHPaE=.874942bd-d03b-407d-99df-880d3928eefe@github.com>

On Thu, 5 May 2022 16:13:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Trivial fix to 3rd party copyright notices.

This pull request has now been integrated.

Changeset: 1277f5d8
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1277f5d84e9c2863595396a471a61d83f8a0298c
Stats:     100 lines in 21 files changed: 64 ins; 0 del; 36 mod

8286154: Fix 3rd party notices in test files

Reviewed-by: darcy, joehw, iris

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

PR: https://git.openjdk.java.net/jdk/pull/8558

From rriggs at openjdk.java.net  Fri May  6 16:20:56 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 6 May 2022 16:20:56 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v5]
In-Reply-To: <Mm6ZoGWlMgP8OqfoGZ5cu0jCwR24t0E-4j6iFxW5nqI=.7dabc177-9e05-4033-b366-f8c29357ecda@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <Mm6ZoGWlMgP8OqfoGZ5cu0jCwR24t0E-4j6iFxW5nqI=.7dabc177-9e05-4033-b366-f8c29357ecda@github.com>
Message-ID: <-kJ7BL857lisVJjUZ6rdRf8Ru5kYSDJ_mQcKIiV5J8k=.45c63768-a40c-4d4f-b9c3-a0b5ecd6a2c6@github.com>

On Fri, 6 May 2022 14:23:00 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

test/jdk/java/lang/ProcessBuilder/Basic.java line 606:

> 604:                 ? Charset.forName(jnuEncoding, Charset.defaultCharset())
> 605:                 : Charset.defaultCharset();
> 606:             if (new String(tested.getBytes(cs), cs).equals(tested)) {

Isn't it always true that the round trip encoding to bytes and back (using the same Charset) to a string is equal()?
And if it is always true, then the if(...) can be removed.

test/jdk/java/lang/System/i18nEnvArg.java line 104:

> 102:             String s = System.getenv(EUC_JP_TEXT);
> 103:             if (!EUC_JP_TEXT.equals(s)) {
> 104:                 System.err.println("ERROR: getenv() returns unexpected data");

Please add the unexpected data `s` to the output string.

test/jdk/java/lang/System/i18nEnvArg.java line 108:

> 106:             if (!EUC_JP_TEXT.equals(args[0])) {
> 107:                 System.err.print("ERROR: Unexpected argument was received: ");
> 108:                 for(char ch : EUC_JP_TEXT.toCharArray()) {

This is the expected value, the previous "Unexpected" labeling might be mis-understood.

test/jdk/java/lang/System/i18nEnvArg.java line 111:

> 109:                    System.err.printf("\\u%04X", (int)ch);
> 110:                 }
> 111:                 System.err.print("<->");

This might be clearer if labeled as the actual/incorrect value and on a separate line.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From rriggs at openjdk.java.net  Fri May  6 16:20:57 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 6 May 2022 16:20:57 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <RIK2pRrJLRPJeUiPX0CrE5bdE_Dryy1UevL7-uNpP1Y=.32375568-449f-4fb5-a5fc-a8b71458257e@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
 <VYYSygrTTDEJNPlbdmIiJ-WkUTfALvLwjThqh2sP55U=.46c77e96-37ba-4cc0-bd4d-217bb3f13353@github.com>
 <8x4pchySckZ09mR3MFAq3hdgwu1IHIV3crYAnDNc-30=.c3405f65-f80c-4974-bb68-be5042e7a945@github.com>
 <SBEaTIxobl1WdeIzFzVEIJ7y-OA8SduR2gsBGmzWcbo=.eff47757-1377-4916-bd77-db3b70514615@github.com>
 <RIK2pRrJLRPJeUiPX0CrE5bdE_Dryy1UevL7-uNpP1Y=.32375568-449f-4fb5-a5fc-a8b71458257e@github.com>
Message-ID: <gugSlF7iFhgdhAnb3SVqNIqJutdj8OZKdeuhx2wIDnw=.04880880-eb52-495e-a2bf-415e521cf0b7@github.com>

On Wed, 4 May 2022 03:01:19 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> Do we need to verify the intermediate byte encoding? Could we simply compare the text given to environ.put() in Start process and System.getenv() in Verify process match?
>
> Hello @naotoj .
> I think if 2nd process' encoder (like UTF-8) and 3rd process' decoder are same encoding, System.getenv() returns expected data.
> Actually the testcase checks 3 parts on Verify process:
> 1. Expected environment variable is defined or not (it uses System.getenv())
> 2. Expected argument is received or not
> 3. Expected environment variable is encoded by proper encoding
> 
> When I ran this testcase with jdk18.0.1, I got following result:
> 
> Unexpected argument was received: \u6F22\u5B57<->\u7FB2\u221A\uFFFD
> Unexpected environment variables: \xE6\xBC\xA2\xE5\xAD\x97\x3D\xE6\xBC\xA2\xE5\xAD\x97
> 
> It means 1st test was passed, 2nd and 3rd test were failed.
> I don't think environment variable issue can be seen without 3rd test.
> Please let me know if you find out another way.

This part of the test is very brittle; I'm pretty sure it will fail on AIX that adds its own environment variables.
It should not fail if it finds the two entries it expects. It should ignore other entries.

I don't see what value it has over checking the entries from System.getEnv(), please elaborate.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From rriggs at openjdk.java.net  Fri May  6 16:37:56 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 6 May 2022 16:37:56 GMT
Subject: RFR: 8286191: misc tests fail due to JDK-8285987 [v3]
In-Reply-To: <1u1FHB8_n-lQP-zR0SdH4m96CnPIMP8sFggRy2xrO30=.c35adb85-09d7-4b06-963c-c745df5930eb@github.com>
References: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
 <1u1FHB8_n-lQP-zR0SdH4m96CnPIMP8sFggRy2xrO30=.c35adb85-09d7-4b06-963c-c745df5930eb@github.com>
Message-ID: <waYNszWp0YguM8Tkn95IsaK6fd756xoQHWHRMFsdzZY=.c836b4ed-8eca-45b4-996f-ce1cea87c77c@github.com>

On Fri, 6 May 2022 06:41:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The isMusl method had to be handled in test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
>> Additionally, the vm.musl predicate seem not to be available in the langtools tests.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore year in ExternalEditorTest, remove test exclusion

Looks good.
Thanks for resolving both ProblemLists.

Hopefully, the real problem and solution on Musl can be found separately.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8556

From mcimadamore at openjdk.java.net  Fri May  6 16:48:11 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 6 May 2022 16:48:11 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v41]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <IITcGvPT5MkqRIuuyrsSYa4pScJv2evL21FmKbuWgu0=.e0ed159e-339a-4df8-8d81-5681840399bb@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

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

  Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/b71c4e93..f823bf84

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=40
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=39-40

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From mchung at openjdk.java.net  Fri May  6 16:55:12 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 6 May 2022 16:55:12 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v41]
In-Reply-To: <IITcGvPT5MkqRIuuyrsSYa4pScJv2evL21FmKbuWgu0=.e0ed159e-339a-4df8-8d81-5681840399bb@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <IITcGvPT5MkqRIuuyrsSYa4pScJv2evL21FmKbuWgu0=.e0ed159e-339a-4df8-8d81-5681840399bb@github.com>
Message-ID: <0liX9cVSEjplWxVgGoM5rN2JZLqN27jSsNxjbucze_o=.fbc3a8fa-acdf-45f4-a717-0fbaa13760d2@github.com>

On Fri, 6 May 2022 16:48:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>   
>   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From lancea at openjdk.java.net  Fri May  6 17:02:51 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 6 May 2022 17:02:51 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v4]
In-Reply-To: <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
Message-ID: <emTtqkVLhhIKMW4rLQFAhJMgq7IOCdhDmJa2dpPox68=.6a6639fc-9579-42cf-b8d5-7fe62ff3ac18@github.com>

On Wed, 4 May 2022 19:16:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add some assertions for entrySet.equals and keySet.equals

I think you have done a nice job on the coverage.

It would be nice for future maintainers if you consider adding comments for all of the tests vs. a subset prior to pushing

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8354

From vromero at openjdk.java.net  Fri May  6 17:06:45 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 6 May 2022 17:06:45 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
Message-ID: <DPtIa69a2NgNDwSmzHyrn-kQAocDY_j8WoMLhlvrA3w=.846c9409-3838-4605-9ad7-1dfcb435ceba@github.com>

On Fri, 6 May 2022 14:09:24 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4217:

> 4215:         }
> 4216:         ListBuffer<BindingSymbol> outBindings = new ListBuffer<>();
> 4217:         List<Type> recordTypes = expectedRecordTypes;

nit: probably a matter of style but why not reusing the already declared `expectedRecordTypes` declaring a new variable seems unnecessary

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Fri May  6 17:43:04 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 17:43:04 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <yfzxxHdWskcWrJOxDBMMeSXV-24cL3E-kdvQ71FwArA=.b1c9b7f7-5fcd-4462-ab4d-137364a9bafd@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
 <yfzxxHdWskcWrJOxDBMMeSXV-24cL3E-kdvQ71FwArA=.b1c9b7f7-5fcd-4462-ab4d-137364a9bafd@github.com>
Message-ID: <uhs6EaCqbGo8ovGL2JmU_qH2MOTg5uJoXbHkl-E382M=.55169332-81c4-4dca-a222-4abe56c6e64c@github.com>

On Fri, 6 May 2022 15:44:22 GMT, Gavin Bierman <gbierman at openjdk.org> wrote:

> > From the JLS specdiff
> > > If the type R names a generic record class then it is a compile-time error if R is not a parameterized type.
> > 
> > 
> > The following snippet raises a `MatchException`. Shouldn't it be a compile-time error?
> > ```
> >         Box<String> r = new Box<>(null);
> > 
> >         switch (r) {
> >             case Box(String s):
> >                 System.out.println("match");
> >         }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > If this is Ok and my understanding is wrong, then why that raises an exception at all? I can make it work (as an unconditional) if I define the Box as `record Box<T extends String>` and now I am confused...
> > ping @GavinBierman @lahodaj
> 
> A couple of issues here. (1) This should be a compile-time error. (2) upon investigation I think there is a bug with the pattern matching code, because the compiler is currently saying that the pattern match here: `Box<String> bs = new Box<>(null); if (bs instanceof Box<String>(String s)) { System.out.println("match!"); }` does not succeed. (It should do). The `MatchException` you are seeing is that the exhaustive pattern switch has no matching label (if you put in a default, you don't get the exception).

Right. Will fix. Sorry for that.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Fri May  6 17:43:07 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 17:43:07 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <DPtIa69a2NgNDwSmzHyrn-kQAocDY_j8WoMLhlvrA3w=.846c9409-3838-4605-9ad7-1dfcb435ceba@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
 <DPtIa69a2NgNDwSmzHyrn-kQAocDY_j8WoMLhlvrA3w=.846c9409-3838-4605-9ad7-1dfcb435ceba@github.com>
Message-ID: <ChVux1eet_iKg6KCHWbow6et4Y_XnduA6-JNRWy-zP8=.7d3011a0-d8cb-4f14-a53a-70be44a8db84@github.com>

On Thu, 5 May 2022 18:11:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4217:
> 
>> 4215:         }
>> 4216:         ListBuffer<BindingSymbol> outBindings = new ListBuffer<>();
>> 4217:         List<Type> recordTypes = expectedRecordTypes;
> 
> nit: probably a matter of style but why not reusing the already declared `expectedRecordTypes` declaring a new variable seems unnecessary

Please note the full `expectedRecordTypes` are used for error reporting, but the reference to `List` in `recordTypes` is overwritten in the loop (at the time of an error report, it may not longer point to the full expected types, and hence cannot be used for error reporting).

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Fri May  6 17:43:11 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 May 2022 17:43:11 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v2]
In-Reply-To: <BRVCNwq7xvWl2AwuqeynSn5BfSc3G7LTaXoee3r3neQ=.90f9863d-7651-405a-b2b4-10cfd75429dd@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
 <BRVCNwq7xvWl2AwuqeynSn5BfSc3G7LTaXoee3r3neQ=.90f9863d-7651-405a-b2b4-10cfd75429dd@github.com>
Message-ID: <eWTffstYzsD322uofKlfl0ixwBOqgxqonqhfmtu5lkY=.e790a2e6-5902-406a-8b79-c1e1f27aad74@github.com>

On Fri, 6 May 2022 14:30:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review feedback.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 752:
> 
>> 750:                                            Iterable<? extends JCCaseLabel> labels) {
>> 751:             Set<Symbol> coveredSymbols = new HashSet<>();
>> 752:             Map<Symbol, List<JCRecordPattern>> deconstructionPatternsBySymbol = new HashMap<>();
> 
> since you seem to have settled on "recordPattern" for implementation names - you can probably revisit some of these names to say "record" instead of "deconstruction".

Right. Will do.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 801:
> 
>> 799:             //i.e. represent all possible combinations.
>> 800:             //This is done by categorizing the patterns based on the type covered by the given
>> 801:             //starting component.
> 
> Example needed here. For instance (I discussed this with @biboudis):
> 
> 
> record Outer(R r) { };
> sealed interface I { };
> class A implements I { };
> class B implements I { };
> sealed interface R { };
> record Foo(I i) implements R { }
> record Bar(I i) implements R { }
> 
> switch (o) {
>    case Outer(Foo(A), Foo(A)):
>    case Outer(Foo(B), Foo(B)):
>    case Outer(Foo(A), Foo(B)):
>    case Outer(Foo(B), Foo(A)):
>    case Outer(Bar(A), Bar(A)):
>    case Outer(Bar(B), Bar(B)):
>    case Outer(Bar(A), Bar(B)):
>    case Outer(Bar(B), Bar(A)):
> }
> 
> 
> Which generates two sets:
> 
> 
>    case Outer(Foo(A), Foo(A)):
>    case Outer(Foo(B), Foo(B)):
>    case Outer(Foo(A), Foo(B)):
>    case Outer(Foo(B), Foo(A)):
> 
> 
> And
> 
> 
>    case Outer(Bar(A), Bar(A)):
>    case Outer(Bar(B), Bar(B)):
>    case Outer(Bar(A), Bar(B)):
>    case Outer(Bar(B), Bar(A)):
> 
> 
> Sorry for being pedantic - this code is tricky and I'm worried we'll all forget exactly how it works in 2 months :-)

Sure. Will try to improve.

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From duke at openjdk.java.net  Fri May  6 17:54:09 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Fri, 6 May 2022 17:54:09 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
Message-ID: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>

JDK-6725221 Standardize obtaining boolean properties with defaults

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

Commit messages:
 - Merge
 - first iteration

Changes: https://git.openjdk.java.net/jdk/pull/8559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8559&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6725221
  Stats: 27 lines in 10 files changed: 1 ins; 4 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8559/head:pull/8559

PR: https://git.openjdk.java.net/jdk/pull/8559

From alanb at openjdk.java.net  Fri May  6 17:59:50 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 6 May 2022 17:59:50 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com>

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777:

> 775:         if (!printStackPropertiesSet && VM.initLevel() >= 1) {
> 776:             printStackWhenAccessFails = GetBooleanAction.
> 777:                 privilegedGetProperty("sun.reflect.debugModuleAccessChecks");

Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From psandoz at openjdk.java.net  Fri May  6 18:24:47 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 6 May 2022 18:24:47 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins
In-Reply-To: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
Message-ID: <9Y7QtzV3UcBRIKAxQ0NRCkDn6Nf3URVhXf04sfgvGzc=.cbf7d6fb-6ca1-4786-8208-e3f8fe7f5fed@github.com>

On Fri, 6 May 2022 15:05:57 GMT, Doug Lea <dl at openjdk.org> wrote:

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool

Changes look good, it will need a CSR.

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From prr at openjdk.java.net  Fri May  6 18:29:44 2022
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 6 May 2022 18:29:44 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <Kz5T3kPgGZRt1KyyScVHeqSmylZ1ZIEaYJa5JOQOl4Q=.6008f002-655c-42e6-8100-89b018436ca8@github.com>

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

The xtoolkit change is fine. I've not looked at anything else
You'll clearly need multiple reviewers for this one.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8559

From smarks at openjdk.java.net  Fri May  6 18:45:36 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 6 May 2022 18:45:36 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v5]
In-Reply-To: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
Message-ID: <PlaY5_lLtyzrr1K4fCjOtU6zP40C5858aupElEPXcd8=.5ac2ac00-cfac-4f89-9ee1-2222401364d9@github.com>

> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.

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

  Add comments on tests that were missing them.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8354/files
  - new: https://git.openjdk.java.net/jdk/pull/8354/files/4bb25edf..fb877d93

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

  Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8354.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8354/head:pull/8354

PR: https://git.openjdk.java.net/jdk/pull/8354

From smarks at openjdk.java.net  Fri May  6 18:45:36 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 6 May 2022 18:45:36 GMT
Subject: RFR: 8285295: Need better testing for IdentityHashMap [v4]
In-Reply-To: <emTtqkVLhhIKMW4rLQFAhJMgq7IOCdhDmJa2dpPox68=.6a6639fc-9579-42cf-b8d5-7fe62ff3ac18@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
 <Ni_hAOYCvuj92ni_UyFrjKe-WBtoF_mYO9IRObBdSnY=.8e0ee4bc-423a-442d-9145-591b534cb8d6@github.com>
 <emTtqkVLhhIKMW4rLQFAhJMgq7IOCdhDmJa2dpPox68=.6a6639fc-9579-42cf-b8d5-7fe62ff3ac18@github.com>
Message-ID: <fa_OmyjTVBAhDluJ3tbC0zkVDKYqwuAW9he0rF1hIl4=.523fa589-29e3-47fb-a0d9-952b73a0b211@github.com>

On Fri, 6 May 2022 16:59:16 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add some assertions for entrySet.equals and keySet.equals
>
> I think you have done a nice job on the coverage.
> 
> It would be nice for future maintainers if you consider adding comments for all of the tests vs. a subset prior to pushing

Thanks @LanceAndersen I've added some comments.

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From smarks at openjdk.java.net  Fri May  6 18:45:37 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 6 May 2022 18:45:37 GMT
Subject: Integrated: 8285295: Need better testing for IdentityHashMap
In-Reply-To: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
References: <RwwDGeKXuwL2Hc7Vb2GhMJd21KyUhaQbbKj4I66j75U=.95715474-278d-40e8-8e1e-b71ba46d32aa@github.com>
Message-ID: <UQ4A8NomZTGt3UAesg2FDnyip497hg5q6z3XmK3I-hA=.2b86dcd1-bc89-406f-a9a6-33ab968faba5@github.com>

On Fri, 22 Apr 2022 03:37:27 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Basic but fairly comprehensive set of tests for `IdentityHashMap`. The patch in the bug report that breaks `IdentityHashMap` now causes several cases in this new test to fail. There's more that could be done, but the new tests cover most of the core functions of `IdentityHashMap`. Unfortunately it seems difficult to merge this with the existing, comprehensive Collections tests (e.g., MOAT.java) because those tests implicity rely on `equals()`-based contract instead of the special-purpose `==`-based contract used by `IdentityHashMap`.

This pull request has now been integrated.

Changeset: 5a1d8f7e
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5a1d8f7e5358d823e9bdeab8056b1de2b050f939
Stats:     678 lines in 1 file changed: 678 ins; 0 del; 0 mod

8285295: Need better testing for IdentityHashMap

Reviewed-by: jpai, lancea

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

PR: https://git.openjdk.java.net/jdk/pull/8354

From naoto at openjdk.java.net  Fri May  6 20:08:05 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 May 2022 20:08:05 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v5]
In-Reply-To: <Mm6ZoGWlMgP8OqfoGZ5cu0jCwR24t0E-4j6iFxW5nqI=.7dabc177-9e05-4033-b366-f8c29357ecda@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <Mm6ZoGWlMgP8OqfoGZ5cu0jCwR24t0E-4j6iFxW5nqI=.7dabc177-9e05-4033-b366-f8c29357ecda@github.com>
Message-ID: <ZsYJj0aGfBXJou0ll3vJFlkGMsJXtUkarVKJwJfWsPo=.4e878ef6-bd16-4976-9e9b-8163d4aa736a@github.com>

On Fri, 6 May 2022 14:23:00 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 77:

> 75:         SUN_JNU_ENCODING = getProperty(props, "sun.jnu.encoding");
> 76:         jnuCharset = Charset.forName(SUN_JNU_ENCODING, Charset.defaultCharset());
> 77:     }

I am not sure it is OK to initialize `Charset` here, as `sun_jnu_encoding` is initialized in `System.initPhase1()` and pulling `Charset` there may cause some init order change. I'd only cache the encoding string here.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From joehw at openjdk.java.net  Fri May  6 20:24:44 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 6 May 2022 20:24:44 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v3]
In-Reply-To: <q4ErCHNEb_FnyyngTzuiJudZmyAc4EiPCgOZw7Eg5_Y=.67ef26dc-94eb-4aed-8858-41174aac8148@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <q4ErCHNEb_FnyyngTzuiJudZmyAc4EiPCgOZw7Eg5_Y=.67ef26dc-94eb-4aed-8858-41174aac8148@github.com>
Message-ID: <Rq5l9O47wkDd4W_eE96lsbfMjPG-Q7y7dLMG-rwGG8g=.7ec2dc89-4ac9-435a-9c76-96cb564a2703@github.com>

On Fri, 6 May 2022 14:33:50 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace the ER_RTF_NOT_SUPPORTED_XRTREEFRAGSELECTWRAPPER key in XPATHErrorResources language files

Changing resource bundles is not required as the L10n resource files update would cover that. As you've modified the files, you'll need to update the license header, using XPATHErrorResources_ja.java as an example and update the year and LastModified tag.

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From martin at openjdk.java.net  Fri May  6 20:28:58 2022
From: martin at openjdk.java.net (Martin Buchholz)
Date: Fri, 6 May 2022 20:28:58 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins
In-Reply-To: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
Message-ID: <k3Zu1BhkllBAI7DbBG1GI-PTgFGCPWccU7vIBO0hgpg=.92f95665-86c2-4da6-963d-170702a5863a@github.com>

On Fri, 6 May 2022 15:05:57 GMT, Doug Lea <dl at openjdk.org> wrote:

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool

test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java line 496:

> 494: 
> 495:     /**
> 496:      * Implictly closing a new pool using try-with-resources terminates it

Typo "Implictly" - twice

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From rriggs at openjdk.java.net  Fri May  6 20:33:50 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 6 May 2022 20:33:50 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v5]
In-Reply-To: <ZsYJj0aGfBXJou0ll3vJFlkGMsJXtUkarVKJwJfWsPo=.4e878ef6-bd16-4976-9e9b-8163d4aa736a@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <Mm6ZoGWlMgP8OqfoGZ5cu0jCwR24t0E-4j6iFxW5nqI=.7dabc177-9e05-4033-b366-f8c29357ecda@github.com>
 <ZsYJj0aGfBXJou0ll3vJFlkGMsJXtUkarVKJwJfWsPo=.4e878ef6-bd16-4976-9e9b-8163d4aa736a@github.com>
Message-ID: <Yjxj0jLIrHN9vvw_yNueTcDOlEyNi3Uuv393527W4Ak=.657714e6-dd40-4a81-a7e7-a2bddfd9d57e@github.com>

On Fri, 6 May 2022 20:03:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 77:
> 
>> 75:         SUN_JNU_ENCODING = getProperty(props, "sun.jnu.encoding");
>> 76:         jnuCharset = Charset.forName(SUN_JNU_ENCODING, Charset.defaultCharset());
>> 77:     }
> 
> I am not sure it is OK to initialize `Charset` here, as `sun_jnu_encoding` is initialized in `System.initPhase1()` and pulling `Charset` there may cause some init order change. I'd only cache the encoding string here.

Note the initialization of `sun.jnu.encoding` in System.java:2142'ish.
This happens before StaticProperty is initialized;  at line 2147.
If the `sun.jnu.encoding` is not supported (this is before Providers are enabled)
then it is forced to `UTF-8`.
So it is the case that the encoding is supported by that point.
Note that `Charset.isSupported(...)` does the full lookup in its implementation.

If it is not supported, the system still comes up using UTF-8 and a warning is printed at line 2282.

Comparing the class initialization order may be a useful thing to cross check.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From naoto at openjdk.java.net  Fri May  6 20:44:45 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 May 2022 20:44:45 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v4]
In-Reply-To: <cttQS8FpqHG48GDEtWDSZq648eR6WwRNgDIWORSxawE=.75f0b3e5-5c72-4bc6-80e1-92861ed65d0a@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <1dZ6o94-xt1oOEevAAO3uYDQrjStchH0FfrHi88V1OE=.bbc63a8f-7959-46fa-ad9c-292c09e80ae5@github.com>
 <tRSCLtwhcT3K3Cdy8VZC4qQGS33-Uss4jEUZNlfjeHw=.4a38432f-8fb3-4ad3-9cb4-906f2ceea673@github.com>
 <cttQS8FpqHG48GDEtWDSZq648eR6WwRNgDIWORSxawE=.75f0b3e5-5c72-4bc6-80e1-92861ed65d0a@github.com>
Message-ID: <sBeWVehOAAQmWVaIglXzJrGsj5xZ3dKCbKPa3-5osjA=.27da3be8-4ca1-435a-a057-9a9dcbb7dabe@github.com>

On Fri, 6 May 2022 14:29:06 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> test/jdk/java/lang/System/i18nEnvArg.java line 110:
>> 
>>> 108:             String s = System.getenv(EUC_JP_TEXT);
>>> 109:             ByteArrayOutputStream baos = new ByteArrayOutputStream();
>>> 110:             PrintStream ps = new PrintStream(baos);
>> 
>> Can utilize try-with-resources pattern.
>
> Use `shouldNotContain()` to find the error message.

I was suggesting `try (ByteArrayOutputStream baos = ...) {` so that no need to clean them up, but I see you removed them. But I prefer not to use `shouldNotContain("ERROR: ")` but to check the return value as before.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From dl at openjdk.java.net  Fri May  6 20:56:25 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Fri, 6 May 2022 20:56:25 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v2]
In-Reply-To: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
Message-ID: <W4KLoNCBmgQeivNaztH3bLi7uh3GM1Avggx7dT2sOEM=.5601c088-e64b-4612-9952-ea15ba0f5a5f@github.com>

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool

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

  Fix doc types

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8577/files
  - new: https://git.openjdk.java.net/jdk/pull/8577/files/57a7c386..5ceb0794

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

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From martin at openjdk.java.net  Fri May  6 21:31:35 2022
From: martin at openjdk.java.net (Martin Buchholz)
Date: Fri, 6 May 2022 21:31:35 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v2]
In-Reply-To: <k3Zu1BhkllBAI7DbBG1GI-PTgFGCPWccU7vIBO0hgpg=.92f95665-86c2-4da6-963d-170702a5863a@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
 <k3Zu1BhkllBAI7DbBG1GI-PTgFGCPWccU7vIBO0hgpg=.92f95665-86c2-4da6-963d-170702a5863a@github.com>
Message-ID: <XZRjCVNBtwFhDyxbjER47WKOFvmApbUEjUuPy41AyyI=.a594bfe2-a924-4b3f-8957-2f314d4dd9c1@github.com>

On Fri, 6 May 2022 20:25:10 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix doc types
>
> test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java line 496:
> 
>> 494: 
>> 495:     /**
>> 496:      * Implictly closing a new pool using try-with-resources terminates it
> 
> Typo "Implictly" - twice

Tests in this file are not being executed.  I think you need:

--- a/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
+++ b/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
@@ -55,7 +55,7 @@ public class ForkJoinPool19Test extends JSR166TestCase {
     }
 
     public static Test suite() {
-        return new TestSuite(ForkJoinPool8Test.class);
+        return new TestSuite(ForkJoinPool19Test.class);
     }
 
     /**

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From martin at openjdk.java.net  Fri May  6 21:31:35 2022
From: martin at openjdk.java.net (Martin Buchholz)
Date: Fri, 6 May 2022 21:31:35 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v2]
In-Reply-To: <XZRjCVNBtwFhDyxbjER47WKOFvmApbUEjUuPy41AyyI=.a594bfe2-a924-4b3f-8957-2f314d4dd9c1@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
 <k3Zu1BhkllBAI7DbBG1GI-PTgFGCPWccU7vIBO0hgpg=.92f95665-86c2-4da6-963d-170702a5863a@github.com>
 <XZRjCVNBtwFhDyxbjER47WKOFvmApbUEjUuPy41AyyI=.a594bfe2-a924-4b3f-8957-2f314d4dd9c1@github.com>
Message-ID: <3q1TEcC566uRhZ2l5THXjIyue-o15UzqMnt2HDSXV-c=.8f03409e-5f6f-49ac-acbd-cedbee308ac6@github.com>

On Fri, 6 May 2022 21:27:53 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java line 496:
>> 
>>> 494: 
>>> 495:     /**
>>> 496:      * Implictly closing a new pool using try-with-resources terminates it
>> 
>> Typo "Implictly" - twice
>
> Tests in this file are not being executed.  I think you need:
> 
> --- a/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
> +++ b/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
> @@ -55,7 +55,7 @@ public class ForkJoinPool19Test extends JSR166TestCase {
>      }
>  
>      public static Test suite() {
> -        return new TestSuite(ForkJoinPool8Test.class);
> +        return new TestSuite(ForkJoinPool19Test.class);
>      }
>  
>      /**

--- a/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
+++ b/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
@@ -55,7 +55,7 @@ public class ForkJoinPool19Test extends JSR166TestCase {
     }
 
     public static Test suite() {
-        return new TestSuite(ForkJoinPool8Test.class);
+        return new TestSuite(ForkJoinPool19Test.class);
     }
 
     /**

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From martin at openjdk.java.net  Fri May  6 21:50:58 2022
From: martin at openjdk.java.net (Martin Buchholz)
Date: Fri, 6 May 2022 21:50:58 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v2]
In-Reply-To: <3q1TEcC566uRhZ2l5THXjIyue-o15UzqMnt2HDSXV-c=.8f03409e-5f6f-49ac-acbd-cedbee308ac6@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
 <k3Zu1BhkllBAI7DbBG1GI-PTgFGCPWccU7vIBO0hgpg=.92f95665-86c2-4da6-963d-170702a5863a@github.com>
 <XZRjCVNBtwFhDyxbjER47WKOFvmApbUEjUuPy41AyyI=.a594bfe2-a924-4b3f-8957-2f314d4dd9c1@github.com>
 <3q1TEcC566uRhZ2l5THXjIyue-o15UzqMnt2HDSXV-c=.8f03409e-5f6f-49ac-acbd-cedbee308ac6@github.com>
Message-ID: <vAxe2TTWUfJrYrxP1yb2RL41N3DxFWqyajtfc_Co6DU=.cc86fb7b-06d8-4c90-819e-ea8d251f5df6@github.com>

On Fri, 6 May 2022 21:28:45 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Tests in this file are not being executed.  I think you need:
>> 
>> --- a/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
>> +++ b/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
>> @@ -55,7 +55,7 @@ public class ForkJoinPool19Test extends JSR166TestCase {
>>      }
>>  
>>      public static Test suite() {
>> -        return new TestSuite(ForkJoinPool8Test.class);
>> +        return new TestSuite(ForkJoinPool19Test.class);
>>      }
>>  
>>      /**
>
> --- a/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
> +++ b/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
> @@ -55,7 +55,7 @@ public class ForkJoinPool19Test extends JSR166TestCase {
>      }
>  
>      public static Test suite() {
> -        return new TestSuite(ForkJoinPool8Test.class);
> +        return new TestSuite(ForkJoinPool19Test.class);
>      }
>  
>      /**

testLazySubmit will cause jtreg to start hanging.
If you wait patiently for 1000 seconds, you'll get a stack dump.

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From duke at openjdk.java.net  Fri May  6 22:05:35 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 6 May 2022 22:05:35 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V) [v4]
In-Reply-To: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
Message-ID: <ecrTSF37lTaIo-0Fx8rdqknSFii-TS33QdJIV9woDDk=.d7c542dd-f80b-4e07-b9a1-0106e63ce4a0@github.com>

> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.

liach 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 six additional commits since the last revision:

 - Move tests
 - Merge branch 'master' into fix/identityhashmap-default
 - Fix assertions
 - Revamp test and changes. Let ci run the tests
 - Fix indent
 - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8259/files
  - new: https://git.openjdk.java.net/jdk/pull/8259/files/fe91721d..c8468ce2

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

  Stats: 53894 lines in 1878 files changed: 35482 ins; 8470 del; 9942 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8259.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8259/head:pull/8259

PR: https://git.openjdk.java.net/jdk/pull/8259

From scolebourne at openjdk.java.net  Fri May  6 22:06:37 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Fri, 6 May 2022 22:06:37 GMT
Subject: RFR: 8286163: micro-optimize Instant.plusSeconds
In-Reply-To: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
References: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
Message-ID: <xyMUe7dP2YMB2F3Xkp7KysToMVcBk6nA2T-XChewBNs=.a94f7817-bf18-4485-a5b6-81f9832f134a@github.com>

On Wed, 4 May 2022 20:27:04 GMT, lennartfricke <duke at openjdk.java.net> wrote:

> Provide micro-benchmark for comparison

Seems reasonable to me. plus(long, long) already has this optimisation.

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

Marked as reviewed by scolebourne (Author).

PR: https://git.openjdk.java.net/jdk/pull/8542

From duke at openjdk.java.net  Fri May  6 22:44:36 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 6 May 2022 22:44:36 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <9HfZ30vnoRR_s3cMkzToyj1ZV-0GXQFcBeoqua8gcM4=.775c0a7a-a38c-403f-948c-b584c89e10ee@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <9HfZ30vnoRR_s3cMkzToyj1ZV-0GXQFcBeoqua8gcM4=.775c0a7a-a38c-403f-948c-b584c89e10ee@github.com>
Message-ID: <oegVb8tThUsMnFxSK7fZcK0HGfrj1r73NJLCJ_SMsZ4=.10a96a1b-bd9a-47ed-8b23-549826c175a8@github.com>

On Thu, 21 Apr 2022 00:48:00 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> Thanks for working on this. Yes I can review and sponsor this change.
> 
> Sorry I got a bit distracted. I started looking at the test here, and this lead me to inquire about what other tests we have for `IdentityHashMap`, and the answer is: not enough. See [JDK-8285295](https://bugs.openjdk.java.net/browse/JDK-8285295). (But that should be handled separately.)

@stuart-marks I have updated the tests to be based off that from [JDK-8285295](https://bugs.openjdk.java.net/browse/JDK-8285295). Anything else that needs an update?

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

PR: https://git.openjdk.java.net/jdk/pull/8259

From dl at openjdk.java.net  Fri May  6 23:01:40 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Fri, 6 May 2022 23:01:40 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v2]
In-Reply-To: <vAxe2TTWUfJrYrxP1yb2RL41N3DxFWqyajtfc_Co6DU=.cc86fb7b-06d8-4c90-819e-ea8d251f5df6@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
 <k3Zu1BhkllBAI7DbBG1GI-PTgFGCPWccU7vIBO0hgpg=.92f95665-86c2-4da6-963d-170702a5863a@github.com>
 <XZRjCVNBtwFhDyxbjER47WKOFvmApbUEjUuPy41AyyI=.a594bfe2-a924-4b3f-8957-2f314d4dd9c1@github.com>
 <3q1TEcC566uRhZ2l5THXjIyue-o15UzqMnt2HDSXV-c=.8f03409e-5f6f-49ac-acbd-cedbee308ac6@github.com>
 <vAxe2TTWUfJrYrxP1yb2RL41N3DxFWqyajtfc_Co6DU=.cc86fb7b-06d8-4c90-819e-ea8d251f5df6@github.com>
Message-ID: <BspuKS3Km-sgtak2KM0riek4X6TQTrn2KoguqSN3oYQ=.0a350fe7-8f85-4d1d-9dea-849e7d8158cc@github.com>

On Fri, 6 May 2022 21:46:58 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> --- a/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
>> +++ b/test/jdk/java/util/concurrent/tck/ForkJoinPool19Test.java
>> @@ -55,7 +55,7 @@ public class ForkJoinPool19Test extends JSR166TestCase {
>>      }
>>  
>>      public static Test suite() {
>> -        return new TestSuite(ForkJoinPool8Test.class);
>> +        return new TestSuite(ForkJoinPool19Test.class);
>>      }
>>  
>>      /**
>
> testLazySubmit will cause jtreg to start hanging.
> If you wait patiently for 1000 seconds, you'll get a stack dump.

Thanks; now fixed (and enabled). (The test didn't do what doc said about joined "by a worker")

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From jjg at openjdk.java.net  Fri May  6 23:38:22 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 6 May 2022 23:38:22 GMT
Subject: RFR: JDK-8286347: incorrect use of `{@link}`
Message-ID: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>

Please review a small doc fix to update incorrect use of `{@link}` on arrays of primitive types.

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

Commit messages:
 - JDK-8286347: incorrect use of `{@link}`

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

PR: https://git.openjdk.java.net/jdk/pull/8584

From mchung at openjdk.java.net  Fri May  6 23:49:43 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 6 May 2022 23:49:43 GMT
Subject: RFR: JDK-8286347: incorrect use of `{@link}`
In-Reply-To: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
References: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
Message-ID: <n-A-kmt1U7M01NTWdIn8CVtlJqz4Nc8ZeR2-BvhVe2k=.aaef92f9-ee44-481c-9053-bc516f1763ba@github.com>

On Fri, 6 May 2022 23:30:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small doc fix to update incorrect use of `{@link}` on arrays of primitive types.

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8584

From wetmore at openjdk.java.net  Sat May  7 00:08:45 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Sat, 7 May 2022 00:08:45 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <pM6XyY27LGmxI28uQudn3alEQB8R_jnmU5uW7uHYaC8=.ae1daeea-8ddd-4a1d-bcfe-b56a02bb137a@github.com>

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

Sorry for the confusion.

The original intent of this bug 14 years ago was to standardize the seclibs code where simple getProperty calls were needed in the context of an AccessController, without having to provide the doProvided calls. i.e. GetBooleanAction.privilegedGetProperty(). This was not intended not other parts of the JDK.

For example: ChannelImpl.java provides a getBooleanProperty() method, which is very similar to GetBooleanAction. I noticed other places in the security where this was being done.

Some of the classes like Debug have been rewritten (SSLLogger), so the issue does not appear to exist there any logger.

The certpath code is working with Security.getProperty(), so that was a red herring.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From iris at openjdk.java.net  Sat May  7 01:00:47 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Sat, 7 May 2022 01:00:47 GMT
Subject: RFR: JDK-8286347: incorrect use of `{@link}`
In-Reply-To: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
References: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
Message-ID: <FYsSoikJh9J4RMniK1354Ht5wurD_uxVrsKahuP9Wxc=.d39e1968-1c29-4b32-8a54-0025359cb594@github.com>

On Fri, 6 May 2022 23:30:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small doc fix to update incorrect use of `{@link}` on arrays of primitive types.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8584

From darcy at openjdk.java.net  Sat May  7 01:31:41 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 7 May 2022 01:31:41 GMT
Subject: RFR: JDK-8286347: incorrect use of `{@link}`
In-Reply-To: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
References: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
Message-ID: <6_TzCYTuvtT_PmrEQOVShmSgg1DcBd4iaSQ4SWej1Zo=.fa7223bd-5938-4d56-ab31-a08ac50a78e4@github.com>

On Fri, 6 May 2022 23:30:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small doc fix to update incorrect use of `{@link}` on arrays of primitive types.

Looks fine in and of itself, but not sure how it will interact with the (presumed) integration of JEP 424: "Foreign Function & Memory API (Preview)" which will at least move the file, if not otherwise modify it.

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

PR: https://git.openjdk.java.net/jdk/pull/8584

From xgong at openjdk.java.net  Sat May  7 01:49:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Sat, 7 May 2022 01:49:40 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <RNdtDRHmdauB0JDZVxiM_GcykLet6ApqTm46SYgBGhQ=.e0c46e0c-7811-4759-b4a0-e2b941730fe9@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <ZU_NGFdXj1afua9vWK7R1W2uHis87SnXhPUegbYqcYw=.50877d5e-7003-4408-8dbd-20ca89ccc442@github.com>
 <PSsn8b0tFvdfFfNw1s0EqBdxgqv0BTL3smIABpPRhIU=.98db7e11-6220-401b-b03a-abc6380d622d@github.com>
 <lgRc3_J4AFK0NPUD0_EuiAwUWj_d4Ka6FzXH3npBARY=.21cf89ef-f605-4f40-b59f-7c57a1faf1d4@github.com>
 <OGo9aUs8yLmsxC1eoalXA3G6yC7U9aEVtkUqrussqCc=.3385b881-7225-4552-aa5a-47a30968afdd@github.com>
 <RNdtDRHmdauB0JDZVxiM_GcykLet6ApqTm46SYgBGhQ=.e0c46e0c-7811-4759-b4a0-e2b941730fe9@github.com>
Message-ID: <z5QIMimXjOhGVyP0sfcsNm0s9oJRSuRll03bzc-UO2A=.b97f2340-a124-4132-a8b6-f1d9a2c4b697@github.com>

On Fri, 6 May 2022 14:59:26 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Make sense! Thanks for the explanation!
>
> Doh! of course. This is not the first and will not be the last time i get caught out by the 2-slot requirement.
> It may be useful to do this:
> 
> Node* mask_arg = is_store ? argument(8) : argument(7);

Yes, the mask argument is got like:

 Node* mask = unbox_vector(is_store ? argument(8) : argument(7), mbox_type, elem_bt, num_elem);

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From alanb at openjdk.java.net  Sat May  7 06:04:51 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 7 May 2022 06:04:51 GMT
Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v14]
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <3Qd4HYCpL8oQztouBMiY7c_7lMBS16X23WTpP65FIzk=.6e4209ba-ce7f-4049-807b-5b6b6ad459ff@github.com>

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Refresh 4e99b5185eef9398c4cc4e90544de4a3153d61a9
 - Merge with 5212535a276a92d96ca20bdcfccfbce956febdb1
 - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3
 - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf
 - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f
 - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5
 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05
 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89
 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a
 - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5212535a...df43e6fc

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

Changes: https://git.openjdk.java.net/jdk/pull/8166/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=13
  Stats: 99468 lines in 1133 files changed: 91198 ins; 3598 del; 4672 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166

PR: https://git.openjdk.java.net/jdk/pull/8166

From itakiguchi at openjdk.java.net  Sat May  7 06:50:40 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sat, 7 May 2022 06:50:40 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v6]
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <rOdoU8PNbp568HcmY5rbmh8YnGmd0Uwqv85vMpT0a5g=.8f49f2e3-2c98-4606-abf2-bc90f25ed35c@github.com>

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

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

  8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8378/files
  - new: https://git.openjdk.java.net/jdk/pull/8378/files/5bd8492f..994a7fd0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8378&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8378&range=04-05

  Stats: 82 lines in 1 file changed: 47 ins; 12 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8378/head:pull/8378

PR: https://git.openjdk.java.net/jdk/pull/8378

From itakiguchi at openjdk.java.net  Sat May  7 06:50:40 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sat, 7 May 2022 06:50:40 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
 <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
Message-ID: <mjfzLI0G8dyTiottOsjL8lcI-bdKSfrCgEnuy6S89YU=.cea2c425-4a3f-4bfa-9c57-7bd33ec7239f@github.com>

On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> Can you clarify the use of different charset properties for the ProcessEnvironment vs the CommandLine strings?
> 
> They are used to decode or encode strings in the APIs to native functions respectively.
> If I understand `native.encoding` was introduced to reflect the default encoding of file contents, while `sun.jnu.encoding` is used to encode filenames.
> 
> I think I would have expected to see `sun.jnu.encoding` to be used in all contexts when encoding/decoding strings to the native representations.  (Assuming its not required for backward compatibility).

Hello @RogerRiggs .
When I executed the new testcase with JDK18.0.1, I got following errors: 

ERROR: argument EUC_JP_TEXT is:
  Actual:   \u7FB2\u221A\uFFFD
  Expected: \u6F22\u5B57
ERROR: Variable EUC_JP_TEXT is encoded by:
  Actual:   \xE6\xBC\xA2\xE5\xAD\x97
  Expected: \xB4\xC1\xBB\xFA
ERROR: Value EUC_JP_TEXT is encoded by:
  Actual:   \xE6\xBC\xA2\xE5\xAD\x97
  Expected: \xB4\xC1\xBB\xFA

The new testcase verifies internal byte data for EUC_JP_TEXT environment variable and value.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From itakiguchi at openjdk.java.net  Sat May  7 06:50:41 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sat, 7 May 2022 06:50:41 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v5]
In-Reply-To: <-kJ7BL857lisVJjUZ6rdRf8Ru5kYSDJ_mQcKIiV5J8k=.45c63768-a40c-4d4f-b9c3-a0b5ecd6a2c6@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <Mm6ZoGWlMgP8OqfoGZ5cu0jCwR24t0E-4j6iFxW5nqI=.7dabc177-9e05-4033-b366-f8c29357ecda@github.com>
 <-kJ7BL857lisVJjUZ6rdRf8Ru5kYSDJ_mQcKIiV5J8k=.45c63768-a40c-4d4f-b9c3-a0b5ecd6a2c6@github.com>
Message-ID: <MhPCxBlDKomL1fq8SVnppRlKn840-0jXUw8Tq0R8ojI=.484d7c21-bc23-4f9e-b8cb-13954eb03146@github.com>

On Fri, 6 May 2022 15:13:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 606:
> 
>> 604:                 ? Charset.forName(jnuEncoding, Charset.defaultCharset())
>> 605:                 : Charset.defaultCharset();
>> 606:             if (new String(tested.getBytes(cs), cs).equals(tested)) {
> 
> Isn't it always true that the round trip encoding to bytes and back (using the same Charset) to a string is equal()?
> And if it is always true, then the if(...) can be removed.

Above code is related to following code:
https://github.com/openjdk/jdk/blob/5212535a276a92d96ca20bdcfccfbce956febdb1/test/jdk/java/lang/ProcessBuilder/Basic.java#L1569-L1570
If `Charset.defaultCharset()` is `UTF-8`, this code is not skipped.
I think this code will be skipped on JDK17 on C locale.

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From alanb at openjdk.java.net  Sat May  7 08:09:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 7 May 2022 08:09:45 GMT
Subject: Integrated: 8284161: Implementation of Virtual Threads (Preview)
In-Reply-To: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
References: <pE3OeXku6-9e09JkjTzVJGRC0hHJSJVQrYmnbY2HeT4=.fd062ac2-1e94-4092-84a3-c9af83c31c9f@github.com>
Message-ID: <qTZgwH4SV8Df3Gz9y3-k6b_F275b3pEmB7wGBYQScK4=.29139c98-29de-41e0-9541-2e686005cb31@github.com>

On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 425: Virtual Threads (Preview).
> 
> We will refresh this PR periodically to pick up changes and fixes from the loom repo.
> 
> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable.
> 
> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo.
> 
> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses.
> 
> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR.
> 
> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time.

This pull request has now been integrated.

Changeset: 9583e365
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9583e3657e43cc1c6f2101a64534564db2a9bd84
Stats:     99468 lines in 1133 files changed: 91198 ins; 3598 del; 4672 mod

8284161: Implementation of Virtual Threads (Preview)

Co-authored-by: Ron Pressler <rpressler at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Andrew Haley <aph at openjdk.org>
Co-authored-by: Rickard B?ckman <rbackman at openjdk.org>
Co-authored-by: Markus Gr?nlund <mgronlun at openjdk.org>
Co-authored-by: Leonid Mesnik <lmesnik at openjdk.org>
Co-authored-by: Serguei Spitsyn <sspitsyn at openjdk.org>
Co-authored-by: Chris Plummer <cjplummer at openjdk.org>
Co-authored-by: Coleen Phillimore <coleenp at openjdk.org>
Co-authored-by: Robbin Ehn <rehn at openjdk.org>
Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Co-authored-by: Thomas Schatzl <tschatzl at openjdk.org>
Co-authored-by: Sergey Kuksenko <skuksenko at openjdk.org>
Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy

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

PR: https://git.openjdk.java.net/jdk/pull/8166

From dl at openjdk.java.net  Sat May  7 10:25:48 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Sat, 7 May 2022 10:25:48 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v3]
In-Reply-To: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
Message-ID: <jxhadbvUNOOg7trazyI_K_Q5eKiwi03jS7lrxcUxTMY=.af93627f-a2bb-4381-981b-cdecad1d9eb3@github.com>

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool

Doug Lea 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 'openjdk:master' into JDK-8286294
 - Fix doc types
 - Override close as explicit no-op for common pool

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8577/files
  - new: https://git.openjdk.java.net/jdk/pull/8577/files/5ceb0794..c276385c

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

  Stats: 103528 lines in 1259 files changed: 93903 ins; 4285 del; 5340 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8577/head:pull/8577

PR: https://git.openjdk.java.net/jdk/pull/8577

From dl at openjdk.java.net  Sat May  7 11:29:32 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Sat, 7 May 2022 11:29:32 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]
In-Reply-To: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
Message-ID: <TxWFutjrplfWY3-KhqXkyKU_D6ISsTU35Yeb4hbaQo0=.0a8ca9ad-4d6c-4d64-ac0c-f22c5ec90982@github.com>

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool

Doug Lea has updated the pull request incrementally with three additional commits since the last revision:

 - Accommodate restrictive SecurityManagers
 - merge with loom updates
   Merge remote-tracking branch 'refs/remotes/origin/JDK-8286294' into JDK-8286294
 - Fix testLazySubmit; enable suite

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8577/files
  - new: https://git.openjdk.java.net/jdk/pull/8577/files/c276385c..9a0d27f4

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

  Stats: 21 lines in 1 file changed: 12 ins; 4 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8577/head:pull/8577

PR: https://git.openjdk.java.net/jdk/pull/8577

From jlahoda at openjdk.java.net  Sat May  7 12:03:04 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Sat, 7 May 2022 12:03:04 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v3]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <UCWsOm3h-S_3hyCCHOU5s3fJojIjOXnb150BEv_yl4w=.a3fe45ff-0510-4b5b-bd32-f5bc29fd477a@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Fixing guards after record patterns.
 - Raw types are not allowed in record patterns.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8516/files
  - new: https://git.openjdk.java.net/jdk/pull/8516/files/90b37c3a..0e384fb3

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

  Stats: 191 lines in 11 files changed: 157 ins; 22 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From jvernee at openjdk.java.net  Sat May  7 12:51:12 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Sat, 7 May 2022 12:51:12 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v4]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <XtNDT2dIarwEvhDUfGddaYBy9BpfTH1VAgNJpsumWSA=.d27a58b2-9f34-4329-aea9-b07db5487503@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:

 - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
 - Merge branch 'master' into JEP-19-VM-IMPL2
 - 8284161: Implementation of Virtual Threads (Preview)
   
   Co-authored-by: Ron Pressler <rpressler at openjdk.org>
   Co-authored-by: Alan Bateman <alanb at openjdk.org>
   Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
   Co-authored-by: Andrew Haley <aph at openjdk.org>
   Co-authored-by: Rickard B?ckman <rbackman at openjdk.org>
   Co-authored-by: Markus Gr?nlund <mgronlun at openjdk.org>
   Co-authored-by: Leonid Mesnik <lmesnik at openjdk.org>
   Co-authored-by: Serguei Spitsyn <sspitsyn at openjdk.org>
   Co-authored-by: Chris Plummer <cjplummer at openjdk.org>
   Co-authored-by: Coleen Phillimore <coleenp at openjdk.org>
   Co-authored-by: Robbin Ehn <rehn at openjdk.org>
   Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
   Co-authored-by: Thomas Schatzl <tschatzl at openjdk.org>
   Co-authored-by: Sergey Kuksenko <skuksenko at openjdk.org>
   Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy
 - 8282218: C1: Missing side effects of dynamic class loading during constant linkage
   
   Reviewed-by: thartmann, kvn
 - 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java
   
   Reviewed-by: mikael
 - 8286263: compiler/c1/TestPinnedIntrinsics.java failed with "RuntimeException: testCurrentTimeMillis failed with -3"
   
   Reviewed-by: thartmann, kvn
 - 8285295: Need better testing for IdentityHashMap
   
   Reviewed-by: jpai, lancea
 - 8286190: Add test to verify constant folding for Enum fields
   
   Reviewed-by: kvn, thartmann
 - 8286154: Fix 3rd party notices in test files
   
   Reviewed-by: darcy, joehw, iris
 - 8286291: G1: Remove unused segment allocator printouts
   
   Reviewed-by: ayang, iwalulya
 - ... and 80 more: https://git.openjdk.java.net/jdk/compare/f823bf84...5cef96f7

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

Changes: https://git.openjdk.java.net/jdk/pull/7959/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=03
  Stats: 117182 lines in 1482 files changed: 100895 ins; 8432 del; 7855 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Sat May  7 12:59:05 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Sat, 7 May 2022 12:59:05 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v5]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <0jKvCItLYrueCki_LnvoP5uRXjLF-a2M5qW6l1Mjpo4=.be3b10da-1c4d-4c41-95db-252ab28ee897@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

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

  Revert "Merge branch 'master' into JEP-19-VM-IMPL2"
  
  This reverts commit 98864b62749f3a482dbb0516a987f38904142042, reversing
  changes made to a7b9f131c4cc5fbec81811941e5c3e164838a88d.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/5cef96f7..f195789f

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

  Stats: 332953 lines in 4896 files changed: 22818 ins; 256179 del; 53956 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Sat May  7 13:05:38 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Sat, 7 May 2022 13:05:38 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v6]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <tLXBfPXVtDb18LpS_yLcKxNiawSXXh9l3im0jYevtaY=.12744e5d-f9b6-49f4-b9b6-32f5427c8845@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee 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 20 new commits since the last revision:

 - Remove unneeded ComputeMoveOrder
 - Remove comment about native calls in lcm.cpp
 - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
   
   Reviewed-by: jvernee, mcimadamore
 - Update riscv and arm stubs
 - Remove spurious ProblemList change
 - Pass pointer to LogStream
 - Polish
 - Replace TraceNativeInvokers flag with unified logging
 - Fix other platforms, take 2
 - Fix other platforms
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/f195789f...e84e3379

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/f195789f..e84e3379

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=04-05

  Stats: 222764 lines in 3783 files changed: 157991 ins; 17628 del; 47145 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Sat May  7 13:05:45 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Sat, 7 May 2022 13:05:45 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v4]
In-Reply-To: <XtNDT2dIarwEvhDUfGddaYBy9BpfTH1VAgNJpsumWSA=.d27a58b2-9f34-4329-aea9-b07db5487503@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <XtNDT2dIarwEvhDUfGddaYBy9BpfTH1VAgNJpsumWSA=.d27a58b2-9f34-4329-aea9-b07db5487503@github.com>
Message-ID: <Wy-NIgECko5wTtnO-k6c0FQo0Ns0M5AW2R4GPYdT7Sg=.87c04481-bfec-42a0-b1bf-d87b2c207a90@github.com>

On Sat, 7 May 2022 12:51:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
>> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
>> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
>> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>  - Merge branch 'master' into JEP-19-VM-IMPL2
>  - 8284161: Implementation of Virtual Threads (Preview)
>    
>    Co-authored-by: Ron Pressler <rpressler at openjdk.org>
>    Co-authored-by: Alan Bateman <alanb at openjdk.org>
>    Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
>    Co-authored-by: Andrew Haley <aph at openjdk.org>
>    Co-authored-by: Rickard B?ckman <rbackman at openjdk.org>
>    Co-authored-by: Markus Gr?nlund <mgronlun at openjdk.org>
>    Co-authored-by: Leonid Mesnik <lmesnik at openjdk.org>
>    Co-authored-by: Serguei Spitsyn <sspitsyn at openjdk.org>
>    Co-authored-by: Chris Plummer <cjplummer at openjdk.org>
>    Co-authored-by: Coleen Phillimore <coleenp at openjdk.org>
>    Co-authored-by: Robbin Ehn <rehn at openjdk.org>
>    Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
>    Co-authored-by: Thomas Schatzl <tschatzl at openjdk.org>
>    Co-authored-by: Sergey Kuksenko <skuksenko at openjdk.org>
>    Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy
>  - 8282218: C1: Missing side effects of dynamic class loading during constant linkage
>    
>    Reviewed-by: thartmann, kvn
>  - 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java
>    
>    Reviewed-by: mikael
>  - 8286263: compiler/c1/TestPinnedIntrinsics.java failed with "RuntimeException: testCurrentTimeMillis failed with -3"
>    
>    Reviewed-by: thartmann, kvn
>  - 8285295: Need better testing for IdentityHashMap
>    
>    Reviewed-by: jpai, lancea
>  - 8286190: Add test to verify constant folding for Enum fields
>    
>    Reviewed-by: kvn, thartmann
>  - 8286154: Fix 3rd party notices in test files
>    
>    Reviewed-by: darcy, joehw, iris
>  - 8286291: G1: Remove unused segment allocator printouts
>    
>    Reviewed-by: ayang, iwalulya
>  - ... and 80 more: https://git.openjdk.java.net/jdk/compare/f823bf84...5cef96f7

I brought in the changes from master after the Virtual Threads integration, but because the PR branch I'm basing on doesn't have those changes, they showed up in the diff. I've undone this mistake by rebasing onto the target branch, which gives a clean diff that should be unchanged from before (but shuffles the commit history to the end of the convo tab).

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From martin at openjdk.java.net  Sat May  7 22:42:47 2022
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sat, 7 May 2022 22:42:47 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]
In-Reply-To: <TxWFutjrplfWY3-KhqXkyKU_D6ISsTU35Yeb4hbaQo0=.0a8ca9ad-4d6c-4d64-ac0c-f22c5ec90982@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
 <TxWFutjrplfWY3-KhqXkyKU_D6ISsTU35Yeb4hbaQo0=.0a8ca9ad-4d6c-4d64-ac0c-f22c5ec90982@github.com>
Message-ID: <B4hA3kJ-WubcYQoW4J3iCQFaJFbGSjT5BMX_ss-428c=.9480cd0a-1700-4a7a-892e-58723c4d114e@github.com>

On Sat, 7 May 2022 11:29:32 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool
>
> Doug Lea has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Accommodate restrictive SecurityManagers
>  - merge with loom updates
>    Merge remote-tracking branch 'refs/remotes/origin/JDK-8286294' into JDK-8286294
>  - Fix testLazySubmit; enable suite

testAdaptInterruptible_Callable_toString belongs in ForkJoinTaskTest.java.  Oh wait, it's already there, commented out!  Why not fix it there?

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From martin at openjdk.java.net  Sun May  8 01:54:44 2022
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 8 May 2022 01:54:44 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]
In-Reply-To: <TxWFutjrplfWY3-KhqXkyKU_D6ISsTU35Yeb4hbaQo0=.0a8ca9ad-4d6c-4d64-ac0c-f22c5ec90982@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
 <TxWFutjrplfWY3-KhqXkyKU_D6ISsTU35Yeb4hbaQo0=.0a8ca9ad-4d6c-4d64-ac0c-f22c5ec90982@github.com>
Message-ID: <1oCwHiPM6T10xwunvqxxYXQe-a4LdOKMWzZ0o5Yi2yU=.1c41bfb9-4499-47b5-83f4-22dcc42e38e5@github.com>

On Sat, 7 May 2022 11:29:32 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool
>
> Doug Lea has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Accommodate restrictive SecurityManagers
>  - merge with loom updates
>    Merge remote-tracking branch 'refs/remotes/origin/JDK-8286294' into JDK-8286294
>  - Fix testLazySubmit; enable suite

Here's a suggested strengthening of testCloseCommonPool:

- close should have "no effect", not just "not terminate".
- the submitted task will be run by the pool ... eventually  (which suggests that closing the common pool maybe should quiesce the pool before returning)
-  I might merge this with testCommonPoolShutDown

    /**
     * Implicitly closing common pool using try-with-resources has no effect.
     */
    public void testCloseCommonPool() {
        ForkJoinTask f = new FibAction(8);
        ForkJoinPool pool;
        try (ForkJoinPool p = pool = ForkJoinPool.commonPool()) {
            p.execute(f);
        }

        assertFalse(pool.isShutdown());
        assertFalse(pool.isTerminating());
        assertFalse(pool.isTerminated());

        String prop = System.getProperty(
            "java.util.concurrent.ForkJoinPool.common.parallelism");
        if (! "0".equals(prop)) {
            f.join();
            checkCompletedNormally(f);
        }
    }

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From prr at openjdk.java.net  Sun May  8 02:25:50 2022
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 8 May 2022 02:25:50 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <ooAju8DRA71gO4MeiJIEASi-GXz2crT958C_LzuOWQY=.431922e2-e465-44df-96df-c542688d703a@github.com>

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

I did wonder why it has security-libs as the sub-category and if the intent was not what we see here.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From victorwssilva at gmail.com  Sun May  8 03:01:44 2022
From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva)
Date: Sun, 8 May 2022 00:01:44 -0300
Subject: Deprecating java.util.Date, java.util.Calendar and
 java.text.DateFormat and their subclasses
Message-ID: <CAJ0GajR4_C1cXyp9Ni=+5rVm_qPXVM5GgUG0SQ6=c07qeM+o+g@mail.gmail.com>

The java.time package was released in Java 8, far back in 2014, more than 8
years ago. It has been a long time since then. Before that, we had the
dreadful infamous java.util.Date, java.util.Calendar,
java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time,
java.sql.Timestamp, java.util.GregorianCalendar, java.text.SimpleDateFormat
and a few other lesser-known obscure cases.

There are plenty of reasons to avoid using Date, Calendar, DateFormat and
their subclasses, otherwise there would be few to no reasons for java.time
to be conceived.

Applications and libraries which used or relied on those legacy classes
already had plenty of time to move on and provide java.time.* alternatives.

No skilled java programmer uses the legacy classes in new applications
except when integrating with legacy APIs.

Using those classes nowadays should be considered at least a bad
programming practice, if not something worse (source of bugs, security
issues, etc).

Novices, unskilled, careless and lazy programmers who should know better
still happily continue to use the legacy classes, pissing off those who are
more enlightened.

So, my proposal is pretty simple: It is time to put a @Deprecated in all of
those (not for removal, though).

First, let's deprecate all of them. Second, any method in the JDK returning
or receiving any of those as a parameter should be equally deprecated. If
there is no replacement method using the relevant classes or interfaces in
the java.time package, one should be created (which is something probably
pretty straightforward).

If any of those methods is abstract or is part of an interface, then we
have a small problem, and it should be solved on a case-by-case analysis,
preferentially by providing a default implementation. I'm sure that some
cases should still exist, but I doubt that any of them would be a
showstopper.

The negative impact is expected to be very small. Popular products like
Spring and Jakarta either already moved on and provided java.time.*
alternatives to their APIs or could do that quickly and easily. Anyone who
is left behind, would only get some [deserved] deprecation warnings.

On the positive impact side, more than just discouraging the usage of the
ugly and annoying API of Date, Calendar and DateFormat for people who
should know better, those classes are a frequent source of bugs that are
hard do track and to debug due to their mutability and thread unsafety.
Thus, we are already way past the time to make the compiler give a warning
to anyone still using them.

What do you think?

From alanb at openjdk.java.net  Sun May  8 05:18:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 8 May 2022 05:18:49 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <ooAju8DRA71gO4MeiJIEASi-GXz2crT958C_LzuOWQY=.431922e2-e465-44df-96df-c542688d703a@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <ooAju8DRA71gO4MeiJIEASi-GXz2crT958C_LzuOWQY=.431922e2-e465-44df-96df-c542688d703a@github.com>
Message-ID: <oPrZ1ZcTJkse6eEWRomgXys5m0pRmNAP2AFKf0Rd9Uo=.5f682889-5e10-400f-a43a-d0c54610fcb2@github.com>

On Sun, 8 May 2022 02:22:08 GMT, Phil Race <prr at openjdk.org> wrote:

> I did wonder why it has security-libs as the sub-category and if the intent was not what we see here.

I suspect the JBS issue was initially created to to look at the usages of getProperty in the security code but it has been extended. The issue is that it changes the meaning of the empty value case in at least two places so each one will require careful attention.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From martin at openjdk.java.net  Sun May  8 05:49:41 2022
From: martin at openjdk.java.net (Martin Buchholz)
Date: Sun, 8 May 2022 05:49:41 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]
In-Reply-To: <TxWFutjrplfWY3-KhqXkyKU_D6ISsTU35Yeb4hbaQo0=.0a8ca9ad-4d6c-4d64-ac0c-f22c5ec90982@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
 <TxWFutjrplfWY3-KhqXkyKU_D6ISsTU35Yeb4hbaQo0=.0a8ca9ad-4d6c-4d64-ac0c-f22c5ec90982@github.com>
Message-ID: <haXxSqgAyeGEmCnOTJJKd1e1MtFpTy71vwl0L1GH-VI=.5d8390c0-389c-4127-a688-631cd2d383a1@github.com>

On Sat, 7 May 2022 11:29:32 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool
>
> Doug Lea has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Accommodate restrictive SecurityManagers
>  - merge with loom updates
>    Merge remote-tracking branch 'refs/remotes/origin/JDK-8286294' into JDK-8286294
>  - Fix testLazySubmit; enable suite

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3533:

> 3531: 
> 3532:     /**
> 3533:      * Unless this is the {@link #commonPool()}, initiates an orderly

clearer everywhere is
{@linkplain #commonPool common pool}

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3536:

> 3534:      * shutdown in which previously submitted tasks are executed, but
> 3535:      * no new tasks will be accepted, and waits until all tasks have
> 3536:      * completed execution and the executor has terminated.

slightly clearer is
s/executor/pool/

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3548:

> 3546:      *
> 3547:      * @throws SecurityException if a security manager exists and
> 3548:      *         shutting down this ExecutorService may manipulate

clearer and more consistent is
s/this ExecutorService/this pool/

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3565:

> 3563:                 while (!terminated) {
> 3564:                     try {
> 3565:                         terminated = awaitTermination(1L, TimeUnit.DAYS);

I would use untimed wait

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From victorwssilva at gmail.com  Sun May  8 05:54:38 2022
From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva)
Date: Sun, 8 May 2022 02:54:38 -0300
Subject: Why does we still need StrictMath?
Message-ID: <CAJ0GajRAgN=z_e7Ep3Uc=2NC-5L87M8TzhKGYDJ1g6hdzEUEtg@mail.gmail.com>

JEP 306 was already delivered some time ago. And with it, we get rid of the
need of that nasty strictfp and the need to have both loose FP and strict
FP.

However, the class java.lang.StrictMath is still around as a normal class,
almost mirroring java.lang.Math, and I really can't understand why.

The javadocs of the Math class says:

"<p>Unlike some of the numeric methods of class {@link java.lang.StrictMath
StrictMath}, all implementations of the equivalent functions of class
{@code Math} are not defined to return the bit-for-bit same results.  This
relaxation permits better-performing implementations where strict
reproducibility is not required.

<p>By default many of the {@code Math} methods simply call the equivalent
method in {@code StrictMath} for their implementation.  Code generators are
encouraged to use platform-specific native libraries or microprocessor
instructions, where available, to provide higher-performance
implementations of {@code Math} methods.  Such higher-performance
implementations still must conform to the specification for {@code Math}."

This seems to be a good motivation on a first look. But:

[a] Eliminating such a thing was not one of the reasons why JEP 306 was
conceived?

[b] Wasn't high-performance with poor-precision one of the things from the
ancient J2SE 1.2 and 1.3 days that isn't a concern anymore because nowadays
processors are much better at FP and we restored always-strict behaviour?

[c] As long as the always-strict FP semantics are respected, if Math
methods could be replaced by higher-performance implementations, why
wouldn't the same apply to StrictMath?

[d] Can someone provide a test case that shows a difference in the
behaviour of Math and StrictMath using some modern hardware and some modern
JVM where JEP 306 was delivered? And if so, is there a reason to call it a
feature instead of a bug?

It might seem that I am being a bit arrogant by making those questions, but
if after JEP 306 there could still be differences in the results produced
by Math and StrictMath, I think that many people would like to know.

Many people (like me right now) assume (and assumptions might be false
sometimes) that since JEP 306 was delivered, there is no need anymore to
have any concern about loose or strict math and with that any concern for
having to carefully choose between Math or StrictMath because both would
have exactly the same behaviour. Many people think/assume that the
motivation that led to StrictMath being created was due to the absence of
the strictfp modifier in the Math class, but since strictfp is a no-op now
and gone from the StrictMath class, then StrictMath would behave exactly
the same as Math.

So, if even after JEP 306 was delivered, there is still any meaningful
observable difference between Math and StrictMath, I think that it should
be emphasized in the javadocs.

Looking at the source code of Math and StrictMath, some methods of Math
delegate to the same method in StrictMath and some methods do the other way
around. Only three methods feature divergent implementations where one
doesn't just delegate to the other. By using delegation, it is ensured that
the methods in one class perfectly mirrors the behaviour of the same method
in the other class (barring stacktraces, SOE and internal or
vendor-specific JVM blackmagic).

[e] If StrictMath is still needed and could produce different results than
Math in some modern hardware, then by the javadocs, it seems to imply that
Math should always delegate to StrictMath and never the other way around.
Why is it not always the case? I think that the answer is simply because
the StrictMath class was largely left unchanged and that delegating in one
way or in the other could then produce a difference when the strictfp
modifier was there, but is there a better reason than that?

If, however, there is no meaningful difference in the results of Math and
StrictMath, my proposal is pretty simple and bold: Deprecate the StrictMath
class and make all its methods simply delegating to Math! Let's all just
use the good old Math class and make our lives better and simpler.

Further, I said that there are three methods that feature divergent
implementations. They are those:

public static double random()
public static double copySign(double magnitude, double sign)
public static float copySign(float magnitude, float sign)

The fact that there are two random() implementations implies the creation
of two java.util.Random instances instead of one. This seems to be a small
bug for me, but one with no observable and/or discernible behavioral
differences. One of them should delegate to the other like the other
methods.

About the copySign methods, the javadocs tell that the difference is the
handling of NaN. This seems to be a nasty difference, since all of the
other methods are expected by users to feature the exact same behaviour in
both classes. My suggestion would be to provide copySignCheckNaN methods in
the Math class or something like.

From aph-open at littlepinkcloud.com  Sun May  8 08:56:07 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Sun, 8 May 2022 09:56:07 +0100
Subject: Why does we still need StrictMath?
In-Reply-To: <CAJ0GajRAgN=z_e7Ep3Uc=2NC-5L87M8TzhKGYDJ1g6hdzEUEtg@mail.gmail.com>
References: <CAJ0GajRAgN=z_e7Ep3Uc=2NC-5L87M8TzhKGYDJ1g6hdzEUEtg@mail.gmail.com>
Message-ID: <0344c75f-05de-e14a-4a00-15c822cceb61@littlepinkcloud.com>

On 5/8/22 06:54, Victor Williams Stafusa da Silva wrote:
> If StrictMath is still needed and could produce different results than
> Math in some modern hardware, then by the javadocs, it seems to imply that
> Math should always delegate to StrictMath and never the other way around.
> Why is it not always the case? I think that the answer is simply because
> the StrictMath class was largely left unchanged and that delegating in one
> way or in the other could then produce a difference when the strictfp
> modifier was there, but is there a better reason than that?

Some targets (x86, in particular) have intrinsics (log, trig) that
are faster than StrictMath and also more accurate. StrictMath is not
about accuracy, but cross-architecture down-to-the-last bit reproducibility.
Whether we still need that reproducibility is, I suppose, something for
debate.

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

From martin.desruisseaux at geomatys.com  Sun May  8 11:10:25 2022
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Sun, 8 May 2022 13:10:25 +0200
Subject: Why does we still need StrictMath?
In-Reply-To: <0344c75f-05de-e14a-4a00-15c822cceb61@littlepinkcloud.com>
References: <CAJ0GajRAgN=z_e7Ep3Uc=2NC-5L87M8TzhKGYDJ1g6hdzEUEtg@mail.gmail.com>
 <0344c75f-05de-e14a-4a00-15c822cceb61@littlepinkcloud.com>
Message-ID: <230c9947-0da4-a655-fb4e-62748af37286@geomatys.com>

Le 08/05/2022 ? 10:56, Andrew Haley a ?crit?:

> Some targets (x86, in particular) have intrinsics (log, trig) that are 
> faster than StrictMath and also more accurate. StrictMath is not about 
> accuracy, but cross-architecture down-to-the-last bit reproducibility. 
> Whether we still need that reproducibility is, I suppose, something 
> for debate.
>
In production code, maybe not. But in test code (e.g. using JUnit), when 
the program does a lot of trigonometric operations (e.g. map 
projections), I have meet cases where a test was successful on a machine 
but failed on another machine. The systematic use of StrictMath in all 
JUnit test code ensure that the difference in behavior is not in the 
test code, so we can focus our debugging effort on the main code.

 ??? Martin



From dl at openjdk.java.net  Sun May  8 12:00:39 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Sun, 8 May 2022 12:00:39 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]
In-Reply-To: <1oCwHiPM6T10xwunvqxxYXQe-a4LdOKMWzZ0o5Yi2yU=.1c41bfb9-4499-47b5-83f4-22dcc42e38e5@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
 <TxWFutjrplfWY3-KhqXkyKU_D6ISsTU35Yeb4hbaQo0=.0a8ca9ad-4d6c-4d64-ac0c-f22c5ec90982@github.com>
 <1oCwHiPM6T10xwunvqxxYXQe-a4LdOKMWzZ0o5Yi2yU=.1c41bfb9-4499-47b5-83f4-22dcc42e38e5@github.com>
Message-ID: <t_qRDFWhHfB0SbTUe3CxfLR0fO3q8b8sn0ngUcqaDmM=.5903bf3e-33a4-492d-85cb-1d64b96c087a@github.com>

On Sun, 8 May 2022 01:51:17 GMT, Martin Buchholz <martin at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Accommodate restrictive SecurityManagers
>>  - merge with loom updates
>>    Merge remote-tracking branch 'refs/remotes/origin/JDK-8286294' into JDK-8286294
>>  - Fix testLazySubmit; enable suite
>
> Here's a suggested strengthening of testCloseCommonPool:
> 
> - close should have "no effect", not just "not terminate".
> - the submitted task will be run by the pool ... eventually  (which suggests that closing the common pool maybe should quiesce the pool before returning)
> -  I might merge this with testCommonPoolShutDown
> 
>     /**
>      * Implicitly closing common pool using try-with-resources has no effect.
>      */
>     public void testCloseCommonPool() {
>         ForkJoinTask f = new FibAction(8);
>         ForkJoinPool pool;
>         try (ForkJoinPool p = pool = ForkJoinPool.commonPool()) {
>             p.execute(f);
>         }
> 
>         assertFalse(pool.isShutdown());
>         assertFalse(pool.isTerminating());
>         assertFalse(pool.isTerminated());
> 
>         String prop = System.getProperty(
>             "java.util.concurrent.ForkJoinPool.common.parallelism");
>         if (! "0".equals(prop)) {
>             f.join();
>             checkCompletedNormally(f);
>         }
>     }

@Martin-Buchholz thanks for test improvements. I'm leaving further FJP tweaks for some other time to avoid possibility of problems after already merging with loom commit

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From dl at openjdk.java.net  Sun May  8 12:08:14 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Sun, 8 May 2022 12:08:14 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v5]
In-Reply-To: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
Message-ID: <auvx0QlRLQHR8sAjqT1CNXnLRQ6rFPOkLu3JKK31-S0=.0bb3de51-c2ac-46df-b2e9-6b9059e08356@github.com>

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool

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

  Test improvements

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8577/files
  - new: https://git.openjdk.java.net/jdk/pull/8577/files/9a0d27f4..4d421ec3

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

  Stats: 30 lines in 2 files changed: 11 ins; 4 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8577/head:pull/8577

PR: https://git.openjdk.java.net/jdk/pull/8577

From victorwssilva at gmail.com  Sun May  8 12:14:13 2022
From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva)
Date: Sun, 8 May 2022 09:14:13 -0300
Subject: Why does we still need StrictMath?
In-Reply-To: <0344c75f-05de-e14a-4a00-15c822cceb61@littlepinkcloud.com>
References: <CAJ0GajRAgN=z_e7Ep3Uc=2NC-5L87M8TzhKGYDJ1g6hdzEUEtg@mail.gmail.com>
 <0344c75f-05de-e14a-4a00-15c822cceb61@littlepinkcloud.com>
Message-ID: <CAJ0GajTnJ3fM8vdtsieZ13Xttck6XMa9=r1ePO-0Zx8FNCkb9w@mail.gmail.com>

Sure, there are the x86 intrinsics. But since JEP 306 was delivered, is
this still valid? The Motivation section of the JEP 306 seems to imply that
this is not the case anymore. Of course, I could just be grossly
misunderstanding what is/was JEP 306 and/or to which depth it meant by
"restore always-strict floating-point semantics", but I don't think that I
am the only one out there.

Em dom., 8 de mai. de 2022 ?s 05:56, Andrew Haley <
aph-open at littlepinkcloud.com> escreveu:

> On 5/8/22 06:54, Victor Williams Stafusa da Silva wrote:
> > If StrictMath is still needed and could produce different results than
> > Math in some modern hardware, then by the javadocs, it seems to imply
> that
> > Math should always delegate to StrictMath and never the other way around.
> > Why is it not always the case? I think that the answer is simply because
> > the StrictMath class was largely left unchanged and that delegating in
> one
> > way or in the other could then produce a difference when the strictfp
> > modifier was there, but is there a better reason than that?
>
> Some targets (x86, in particular) have intrinsics (log, trig) that
> are faster than StrictMath and also more accurate. StrictMath is not
> about accuracy, but cross-architecture down-to-the-last bit
> reproducibility.
> Whether we still need that reproducibility is, I suppose, something for
> debate.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>

From victorwssilva at gmail.com  Sun May  8 12:15:38 2022
From: victorwssilva at gmail.com (Victor Williams Stafusa da Silva)
Date: Sun, 8 May 2022 09:15:38 -0300
Subject: Why does we still need StrictMath?
In-Reply-To: <230c9947-0da4-a655-fb4e-62748af37286@geomatys.com>
References: <CAJ0GajRAgN=z_e7Ep3Uc=2NC-5L87M8TzhKGYDJ1g6hdzEUEtg@mail.gmail.com>
 <0344c75f-05de-e14a-4a00-15c822cceb61@littlepinkcloud.com>
 <230c9947-0da4-a655-fb4e-62748af37286@geomatys.com>
Message-ID: <CAJ0GajSD8tQAmQYeP-VSRU2QFYd=QMNZwio4d7y4pcfUZ85zJA@mail.gmail.com>

Was that using Java 17+, which included JEP 306 delivered?

Em dom., 8 de mai. de 2022 ?s 08:10, Martin Desruisseaux <
martin.desruisseaux at geomatys.com> escreveu:

> Le 08/05/2022 ? 10:56, Andrew Haley a ?crit :
>
> > Some targets (x86, in particular) have intrinsics (log, trig) that are
> > faster than StrictMath and also more accurate. StrictMath is not about
> > accuracy, but cross-architecture down-to-the-last bit reproducibility.
> > Whether we still need that reproducibility is, I suppose, something
> > for debate.
> >
> In production code, maybe not. But in test code (e.g. using JUnit), when
> the program does a lot of trigonometric operations (e.g. map
> projections), I have meet cases where a test was successful on a machine
> but failed on another machine. The systematic use of StrictMath in all
> JUnit test code ensure that the difference in behavior is not in the
> test code, so we can focus our debugging effort on the main code.
>
>      Martin
>
>
>

From martin.desruisseaux at geomatys.com  Sun May  8 12:44:36 2022
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Sun, 8 May 2022 14:44:36 +0200
Subject: Why does we still need StrictMath?
In-Reply-To: <CAJ0GajSD8tQAmQYeP-VSRU2QFYd=QMNZwio4d7y4pcfUZ85zJA@mail.gmail.com>
References: <CAJ0GajRAgN=z_e7Ep3Uc=2NC-5L87M8TzhKGYDJ1g6hdzEUEtg@mail.gmail.com>
 <0344c75f-05de-e14a-4a00-15c822cceb61@littlepinkcloud.com>
 <230c9947-0da4-a655-fb4e-62748af37286@geomatys.com>
 <CAJ0GajSD8tQAmQYeP-VSRU2QFYd=QMNZwio4d7y4pcfUZ85zJA@mail.gmail.com>
Message-ID: <786cbd8d-ce78-01c4-890e-47cfe7a1bd5b@geomatys.com>

Le 08/05/2022 ? 14:15, Victor Williams Stafusa da Silva a ?crit?:

> Was that using Java 17+, which included JEP 306 delivered?
>
No, but my understanding is that JEP 306 does not apply to Math versus 
StrictMath behavior. In my understanding, the strictfp keyword was only 
about the use of extended exponent value set in Pentium 80 bits floating 
point values. It impacts the behavior of arithmetic operations + - * /, 
but my (maybe wrong) understanding is that it does not impact which 
processor instruction is used for implementing Math.sin, cos, etc.

 ??? Martin



From alanb at openjdk.java.net  Sun May  8 15:16:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 8 May 2022 15:16:49 GMT
Subject: RFR: 8286298: Remove unused methods in sun.invoke.util.VerifyType
In-Reply-To: <hm_DCon8SD1b9B3sGDnoRHndjsIU5QKMa2czmHBxRlU=.6a79e0ab-9199-42a8-a69d-183fbfa92cb3@github.com>
References: <hm_DCon8SD1b9B3sGDnoRHndjsIU5QKMa2czmHBxRlU=.6a79e0ab-9199-42a8-a69d-183fbfa92cb3@github.com>
Message-ID: <sy-MAk4lR_YlySWouMllerbGuc2qbRt7cSuH6Qj0SeU=.feef1714-1669-45f6-8ce6-b741336bae40@github.com>

On Fri, 6 May 2022 11:32:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few untested and unused methods in `VerifyType` which can be removed. (Possibly used by native JSR 292 implementations in JDK 7).

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8570

From itakiguchi at openjdk.java.net  Sun May  8 16:16:51 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Sun, 8 May 2022 16:16:51 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v6]
In-Reply-To: <rOdoU8PNbp568HcmY5rbmh8YnGmd0Uwqv85vMpT0a5g=.8f49f2e3-2c98-4606-abf2-bc90f25ed35c@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <rOdoU8PNbp568HcmY5rbmh8YnGmd0Uwqv85vMpT0a5g=.8f49f2e3-2c98-4606-abf2-bc90f25ed35c@github.com>
Message-ID: <zJ484zuiwedXxmR6o0vFeVAvpr5F0VhOlxZZ8MOvctg=.654d9cdc-323d-47a5-b04c-f5342a9769af@github.com>

On Sat, 7 May 2022 06:50:40 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

I checked internal data

$ cat StaticPropertyVals.java 
import java.lang.reflect.*;

public class StaticPropertyVals {
  public static void main(String[] args) throws Exception {
    Class<?> cls = Class.forName("jdk.internal.util.StaticProperty");
    for (Field fid : cls.getDeclaredFields()) {
      if (Modifier.isStatic(fid.getModifiers())) {
        fid.setAccessible(true);
        System.out.println(fid.getName() + "=" + fid.get(null));
      }
    }
  }
}
$ env LANG=kk_KZ.pt154 LC_ALL=kk_KZ.pt154 java -XshowSettings:properties --add-opens=java.base/jdk.internal.util=ALL-UNNAMED StaticPropertyVals 2>&1 | egrep -i 'encoding|charset'
WARNING: The encoding of the underlying platform's file system is not supported: PT154
    file.encoding = UTF-8
    native.encoding = PT154
    sun.io.unicode.encoding = UnicodeLittle
    sun.jnu.encoding = UTF-8
NATIVE_ENCODING=PT154
FILE_ENCODING=UTF-8
SUN_JNU_ENCODING=UTF-8
jnuCharset=UTF-8
$

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

PR: https://git.openjdk.java.net/jdk/pull/8378

From lmesnik at openjdk.java.net  Sun May  8 22:06:02 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sun, 8 May 2022 22:06:02 GMT
Subject: RFR: 8284550: test failure_handler is not properly invoking jhsdb
 jstack, resulting in failure to produce a stack when a test times out
Message-ID: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>

?resulting in failure to produce a stack when a test times out

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

Commit messages:
 - 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out

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

PR: https://git.openjdk.java.net/jdk/pull/8588

From dholmes at openjdk.java.net  Sun May  8 22:24:42 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 8 May 2022 22:24:42 GMT
Subject: RFR: 8284550: test failure_handler is not properly invoking jhsdb
 jstack, resulting in failure to produce a stack when a test times out
In-Reply-To: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>
References: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>
Message-ID: <AnMNUSOjf-GdhSK48T5advyTps32jMJ7zYJPncvIn98=.f4e7c32d-5542-413f-a064-ebbe4a97e76a@github.com>

On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ?resulting in failure to produce a stack when a test times out

Looks good.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8588

From redestad at openjdk.java.net  Sun May  8 22:43:36 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 8 May 2022 22:43:36 GMT
Subject: RFR: 8286163: micro-optimize Instant.plusSeconds
In-Reply-To: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
References: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
Message-ID: <WwNGXBAhS2crX52Y5mi4NdwmnXH-yO-8gbgdPt6BeOI=.9efb33cc-dba3-4bf2-bf0c-89846299450c@github.com>

On Wed, 4 May 2022 20:27:04 GMT, lennartfricke <duke at openjdk.java.net> wrote:

> Provide micro-benchmark for comparison

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8542

From redestad at openjdk.java.net  Sun May  8 22:43:36 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 8 May 2022 22:43:36 GMT
Subject: RFR: 8286163: micro-optimize Instant.plusSeconds
In-Reply-To: <xyMUe7dP2YMB2F3Xkp7KysToMVcBk6nA2T-XChewBNs=.a94f7817-bf18-4485-a5b6-81f9832f134a@github.com>
References: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
 <xyMUe7dP2YMB2F3Xkp7KysToMVcBk6nA2T-XChewBNs=.a94f7817-bf18-4485-a5b6-81f9832f134a@github.com>
Message-ID: <fafcp12NXZ0S0eTAcrrW7geG0yz4qmdVokZYInW7it8=.c92aa15c-f678-425d-a844-b9bfd9f47e17@github.com>

On Fri, 6 May 2022 22:02:58 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

> Seems reasonable to me. plus(long, long) already has this optimisation.

If it already had this optimization then why change anything? I think you're referring to the check for `0` to return `this` then that is something `plusSeconds` will need to retain for parity. The optimization here appears to be the avoiding of added arithmetic for dealing with nanoseconds. And though it bothers me that the JIT doesn't optimize this better (given that the nanosecond parameter to `plus(long, long)` is a constant zero) the patch does seem reasonable.

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

PR: https://git.openjdk.java.net/jdk/pull/8542

From jjg at openjdk.java.net  Mon May  9 00:59:38 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 9 May 2022 00:59:38 GMT
Subject: RFR: JDK-8286347: incorrect use of `{@link}`
In-Reply-To: <6_TzCYTuvtT_PmrEQOVShmSgg1DcBd4iaSQ4SWej1Zo=.fa7223bd-5938-4d56-ab31-a08ac50a78e4@github.com>
References: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
 <6_TzCYTuvtT_PmrEQOVShmSgg1DcBd4iaSQ4SWej1Zo=.fa7223bd-5938-4d56-ab31-a08ac50a78e4@github.com>
Message-ID: <u1g07aFYrvqb8fRJUKh7lmcsJIOBN4ldFf3IW78KNNE=.9f4f332e-54c4-4a11-9fe9-5d004c049f1b@github.com>

On Sat, 7 May 2022 01:27:57 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Looks fine in and of itself, but not sure how it will interact with the (presumed) integration of JEP 424: "Foreign Function & Memory API (Preview)" which will at least move the file, if not otherwise modify it.

I assume the changes are small and localized enough to not trigger any significant conflict.

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

PR: https://git.openjdk.java.net/jdk/pull/8584

From alanb at openjdk.java.net  Mon May  9 06:03:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 9 May 2022 06:03:47 GMT
Subject: RFR: 8284550: test failure_handler is not properly invoking jhsdb
 jstack, resulting in failure to produce a stack when a test times out
In-Reply-To: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>
References: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>
Message-ID: <PoucEZPDQGXWg4d-9qU5Nwx8Z3cFihlHWU0PEsRxiJU=.15c71e61-5457-4002-841e-9124c07a8970@github.com>

On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ?resulting in failure to produce a stack when a test times out

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8588

From duke at openjdk.java.net  Mon May  9 06:38:29 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Mon, 9 May 2022 06:38:29 GMT
Subject: RFR: 8238373: Punctuation should be same in jlink help usage on
 Japanese language [v2]
In-Reply-To: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
References: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
Message-ID: <7w6P30l41_L74tNKPhy1CTprXvXbn7Zy16XS0SWVckI=.49454ba3-9348-4f7c-9d53-8905d156dad1@github.com>

> When showing help for the jlink command in a Japanese locale, delimiters of option's aliases are a mixture of "," and \u3001. Delimiter should be unified to ",".
> As the same, there is a inconsistency of delimiters in the jar command help in a Japanese locale, and "," should be used.
> Similarly, the javap command help uses space as delimiters other than the module option in all locales. This inconsistency should also be corrected.
> 
> Would you please review this fix?

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

  8238373: Punctuation should be same in jlink help usage on Japanese language

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8417/files
  - new: https://git.openjdk.java.net/jdk/pull/8417/files/5163b9df..c881ec75

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

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

PR: https://git.openjdk.java.net/jdk/pull/8417

From duke at openjdk.java.net  Mon May  9 06:40:24 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Mon, 9 May 2022 06:40:24 GMT
Subject: RFR: 8238373: Punctuation should be same in jlink help usage on
 Japanese language [v2]
In-Reply-To: <rV9tqb5vwiaJb5Ac52dQmc3QsjJivKXypIXWbofNIls=.15a473d5-09ea-4184-aab5-15d6ce243ac1@github.com>
References: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
 <rV9tqb5vwiaJb5Ac52dQmc3QsjJivKXypIXWbofNIls=.15a473d5-09ea-4184-aab5-15d6ce243ac1@github.com>
Message-ID: <hHTl87bMwzSt960NyTiHjPdRxUlH0dbpeAChOW1MDfQ=.bc772bfa-2c36-4458-90f6-be8377f23343@github.com>

On Wed, 27 Apr 2022 16:42:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks fine to me. Nit: please modify the copyright years for `javap` properties files, as you modified the base (`javap.properties`) file.

I?m sorry for the late reply.  
Thank you for your advice. I modified the copyright years for all files.

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

PR: https://git.openjdk.java.net/jdk/pull/8417

From duke at openjdk.java.net  Mon May  9 06:43:53 2022
From: duke at openjdk.java.net (Shruthi)
Date: Mon, 9 May 2022 06:43:53 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v4]
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <WBdJUo37kekLF-4K_GL1OgOq7lATDU5Lk9SuLd1iGbM=.553bce09-1b3b-4d22-8db3-8c59aa213c3b@github.com>

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

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

  Add last modified tag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8318/files
  - new: https://git.openjdk.java.net/jdk/pull/8318/files/c294a150..ef9d4444

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

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Mon May  9 06:57:48 2022
From: duke at openjdk.java.net (lennartfricke)
Date: Mon, 9 May 2022 06:57:48 GMT
Subject: RFR: 8286163: micro-optimize Instant.plusSeconds
In-Reply-To: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
References: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
Message-ID: <JJoby93uOGOQhG7ALRsaiqkPr9_mZCodAPsKMaQGvLc=.c0106a2c-35a1-4695-a2ad-07afff22a55c@github.com>

On Wed, 4 May 2022 20:27:04 GMT, lennartfricke <duke at openjdk.java.net> wrote:

> Provide micro-benchmark for comparison

The speedup is roughly 1.6.

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

PR: https://git.openjdk.java.net/jdk/pull/8542

From duke at openjdk.java.net  Mon May  9 07:00:34 2022
From: duke at openjdk.java.net (Shruthi)
Date: Mon, 9 May 2022 07:00:34 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v5]
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <drsenHv3gH1CQqIVvfjj_zFD9oHqZvQQhTJFpWHUAVA=.afcb920c-7236-4aa5-b73a-af3a44f075df@github.com>

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

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

  Add last modified tag

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8318/files
  - new: https://git.openjdk.java.net/jdk/pull/8318/files/ef9d4444..b1dcd44c

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

  Stats: 943 lines in 1 file changed: 0 ins; 943 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8318/head:pull/8318

PR: https://git.openjdk.java.net/jdk/pull/8318

From aph-open at littlepinkcloud.com  Mon May  9 08:03:37 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 9 May 2022 09:03:37 +0100
Subject: Why does we still need StrictMath?
In-Reply-To: <786cbd8d-ce78-01c4-890e-47cfe7a1bd5b@geomatys.com>
References: <CAJ0GajRAgN=z_e7Ep3Uc=2NC-5L87M8TzhKGYDJ1g6hdzEUEtg@mail.gmail.com>
 <0344c75f-05de-e14a-4a00-15c822cceb61@littlepinkcloud.com>
 <230c9947-0da4-a655-fb4e-62748af37286@geomatys.com>
 <CAJ0GajSD8tQAmQYeP-VSRU2QFYd=QMNZwio4d7y4pcfUZ85zJA@mail.gmail.com>
 <786cbd8d-ce78-01c4-890e-47cfe7a1bd5b@geomatys.com>
Message-ID: <c7a02682-ec9d-09d7-b0ea-216c8a37cd46@littlepinkcloud.com>

On 5/8/22 13:44, Martin Desruisseaux wrote:
> Le 08/05/2022 ? 14:15, Victor Williams Stafusa da Silva a ?crit?:
> 
>> Was that using Java 17+, which included JEP 306 delivered?
>>
> No, but my understanding is that JEP 306 does not apply to Math versus
> StrictMath behavior. In my understanding, the strictfp keyword was only
> about the use of extended exponent value set in Pentium 80 bits floating
> point values. It impacts the behavior of arithmetic operations + - * /,
> but my (maybe wrong) understanding is that it does not impact which
> processor instruction is used for implementing Math.sin, cos, etc.

You're right.

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

From aph-open at littlepinkcloud.com  Mon May  9 08:05:43 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 9 May 2022 09:05:43 +0100
Subject: Why does we still need StrictMath?
In-Reply-To: <CAJ0GajTnJ3fM8vdtsieZ13Xttck6XMa9=r1ePO-0Zx8FNCkb9w@mail.gmail.com>
References: <CAJ0GajRAgN=z_e7Ep3Uc=2NC-5L87M8TzhKGYDJ1g6hdzEUEtg@mail.gmail.com>
 <0344c75f-05de-e14a-4a00-15c822cceb61@littlepinkcloud.com>
 <CAJ0GajTnJ3fM8vdtsieZ13Xttck6XMa9=r1ePO-0Zx8FNCkb9w@mail.gmail.com>
Message-ID: <c6167b6a-ee3e-fa69-8ffa-d566d304ca09@littlepinkcloud.com>

On 5/8/22 13:14, Victor Williams Stafusa da Silva wrote:
> Sure, there are the x86 intrinsics. But since JEP 306 was delivered, is this still valid? The Motivation section of the JEP 306 seems to imply that this is not the case anymore. Of course, I could just be grossly misunderstanding what is/was JEP 306?and/or to which depth it meant by "restore always-strict floating-point semantics", but I don't think that I am the only one out there.

JEP 306 isn't about j.l.StrictMath. The Description section of 306
says what it's really about.

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

From mcimadamore at openjdk.java.net  Mon May  9 08:20:58 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 May 2022 08:20:58 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v3]
In-Reply-To: <UCWsOm3h-S_3hyCCHOU5s3fJojIjOXnb150BEv_yl4w=.a3fe45ff-0510-4b5b-bd32-f5bc29fd477a@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <UCWsOm3h-S_3hyCCHOU5s3fJojIjOXnb150BEv_yl4w=.a3fe45ff-0510-4b5b-bd32-f5bc29fd477a@github.com>
Message-ID: <owiWOG27psDepURelkZYBMi8MCxQVyxCMf3YoLU45_w=.e61a75f2-01f4-46b6-9a4d-8ea35fdf8884@github.com>

On Sat, 7 May 2022 12:03:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixing guards after record patterns.
>  - Raw types are not allowed in record patterns.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4208:

> 4206:         if (site.tsym.kind == Kind.TYP && ((ClassSymbol) site.tsym).isRecord()) {
> 4207:             ClassSymbol record = (ClassSymbol) site.tsym;
> 4208:             if (record.type.getTypeArguments().nonEmpty()) {

There is a `Type::isRaw()` - I supposed you tried that one? Doesn't it do what you want?

test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out line 3:

> 1: DeconstructionPatternErrors.java:15:28: compiler.err.underscore.as.identifier
> 2: DeconstructionPatternErrors.java:15:29: compiler.err.expected: token.identifier
> 3: DeconstructionPatternErrors.java:43:37: compiler.err.illegal.start.of.type

should error be more specific here? E.g. diamond not supported with type test pattern?

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From mcimadamore at openjdk.java.net  Mon May  9 08:26:35 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 May 2022 08:26:35 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v42]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <P965vI1xrotIG0xVql0IUcl1rfywCan2ci37LPj56ok=.a9667d42-c7ac-485e-bc01-88637207ec34@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:

 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Add tests for loaderLookup/restricted method corner cases
 - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
   * Tweak restricted method check to work when there's no caller class
 - Tweak examples in SymbolLookup javadoc
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Tweak support for Linker lookup
   Improve javadoc of SymbolLookup
 - Tweak Addressable javadoc
 - Downcall and upcall tests use wrong layout which is missing some trailing padding
 - ... and 52 more: https://git.openjdk.java.net/jdk/compare/39f4434f...3c88a2ef

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

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=41
  Stats: 65712 lines in 373 files changed: 43721 ins; 19432 del; 2559 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From duke at openjdk.java.net  Mon May  9 09:25:15 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 09:25:15 GMT
Subject: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java
 fails with expected [true] but found [false] [v2]
In-Reply-To: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
References: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
Message-ID: <xFy67sI4lu8NWdBi8E8ANi63JLTOA9aMBYwm40BCoQY=.35a1d96b-9dde-48fe-b153-4a2fc70b7372@github.com>

> Please review these small changes to address intermittent failures, as of JDK-8274517.
> 
> - Usage of jdk.test.lib.RandomFactory for reproducible random generation.
> - Slightly less restrictive assertion about badParallelStreamError on L94 (former L88).
> - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18.
> 
> While these changes do not necessarily guarantee absence of intermittent failures, the usage of jdk.test.lib.RandomFactory should at least help to pin down specific double sequences that do not pass the test.
> 
> There is still an inherent variability due to the use of parallel streams, though. As double addition is not perfectly associative, even a fully known sequence of doubles may lead to slightly different results with parallelization.

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

 - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with
   expected [true] but found [false]
   
   Merge branch 'master' into JDK-8274517
 - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false]

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8290/files
  - new: https://git.openjdk.java.net/jdk/pull/8290/files/769855cd..6035eeab

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

  Stats: 154484 lines in 2948 files changed: 127735 ins; 11899 del; 14850 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8290/head:pull/8290

PR: https://git.openjdk.java.net/jdk/pull/8290

From duke at openjdk.java.net  Mon May  9 09:26:20 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 09:26:20 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v10]
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <-Qu0AFdlNncqx9-RX-1iXm0HwUWBMJesSjyG9HVqrjE=.6a756525-974e-497b-8914-045b3af44862@github.com>

> Hello,
> 
> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
> 
> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
> 
> 
> Greetings
> Raffaello

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Merge branch 'master' into JDK-4511638
 - 4511638: Double.toString(double) sometimes produces incorrect results
 - 4511638: Double.toString(double) sometimes produces incorrect results
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Merge branch 'master' into JDK-4511638
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Adapted hashes in ElementStructureTest.java
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Merge branch 'master' into JDK-4511638
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Enhanced intervals in MathUtils.
   Updated references to Schubfach v4.
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Merge branch 'master' into JDK-4511638
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments.
 - 4511638: Double.toString(double) sometimes produces incorrect results
   
   Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/d4474b58...bd323d15

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

Changes: https://git.openjdk.java.net/jdk/pull/3402/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=09
  Stats: 23708 lines in 16 files changed: 23625 ins; 46 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402

PR: https://git.openjdk.java.net/jdk/pull/3402

From duke at openjdk.java.net  Mon May  9 09:26:58 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 09:26:58 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v2]
In-Reply-To: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
Message-ID: <6wOeHEcFHPv0-dg-v19u3S1SNUXTa7FcUJGdrrEFoOs=.21bc13d5-dba5-4011-9f16-aae52707d4c0@github.com>

> Add a family of "safe" cast methods.

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

 - 8279986: methods Math::asXExact for safely checked primitive casts
   
   Merge branch 'master' into JDK-8279986
 - 8279986: methods Math::asXExact for safely checked primitive casts
   
   Merge branch 'master' into JDK-8279986
 - 8279986: methods Math::asXExact for safely checked primitive casts
 - 8279986: methods Math::asXExact for safely checked primitive casts

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8548/files
  - new: https://git.openjdk.java.net/jdk/pull/8548/files/4d0924c5..7be0f9de

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

  Stats: 103190 lines in 1255 files changed: 93727 ins; 4219 del; 5244 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548

PR: https://git.openjdk.java.net/jdk/pull/8548

From duke at openjdk.java.net  Mon May  9 09:30:54 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 09:30:54 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v10]
In-Reply-To: <-Qu0AFdlNncqx9-RX-1iXm0HwUWBMJesSjyG9HVqrjE=.6a756525-974e-497b-8914-045b3af44862@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <-Qu0AFdlNncqx9-RX-1iXm0HwUWBMJesSjyG9HVqrjE=.6a756525-974e-497b-8914-045b3af44862@github.com>
Message-ID: <RQebanZhtlm_be_NXoJMekvpnEjpmL58oc0r4fqfl94=.898a8cee-ce6d-4e15-bf06-969912677274@github.com>

On Mon, 9 May 2022 09:26:20 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Adapted hashes in ElementStructureTest.java
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Enhanced intervals in MathUtils.
>    Updated references to Schubfach v4.
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments.
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/d4474b58...bd323d15

Post Loom merge

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

PR: https://git.openjdk.java.net/jdk/pull/3402

From duke at openjdk.java.net  Mon May  9 09:30:56 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 09:30:56 GMT
Subject: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java
 fails with expected [true] but found [false] [v2]
In-Reply-To: <xFy67sI4lu8NWdBi8E8ANi63JLTOA9aMBYwm40BCoQY=.35a1d96b-9dde-48fe-b153-4a2fc70b7372@github.com>
References: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
 <xFy67sI4lu8NWdBi8E8ANi63JLTOA9aMBYwm40BCoQY=.35a1d96b-9dde-48fe-b153-4a2fc70b7372@github.com>
Message-ID: <9hFSL-6pt9lvKtEWWOjeH3wejmbSo-fL8mByJ1hWBuQ=.8a379469-99e9-484e-815a-ab45a609fc01@github.com>

On Mon, 9 May 2022 09:25:15 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Please review these small changes to address intermittent failures, as of JDK-8274517.
>> 
>> - Usage of jdk.test.lib.RandomFactory for reproducible random generation.
>> - Slightly less restrictive assertion about badParallelStreamError on L94 (former L88).
>> - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18.
>> 
>> While these changes do not necessarily guarantee absence of intermittent failures, the usage of jdk.test.lib.RandomFactory should at least help to pin down specific double sequences that do not pass the test.
>> 
>> There is still an inherent variability due to the use of parallel streams, though. As double addition is not perfectly associative, even a fully known sequence of doubles may lead to slightly different results with parallelization.
>
> Raffaello Giulietti 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:
> 
>  - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with
>    expected [true] but found [false]
>    
>    Merge branch 'master' into JDK-8274517
>  - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false]

Post Loom merge

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

PR: https://git.openjdk.java.net/jdk/pull/8290

From duke at openjdk.java.net  Mon May  9 09:31:54 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 09:31:54 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v2]
In-Reply-To: <6wOeHEcFHPv0-dg-v19u3S1SNUXTa7FcUJGdrrEFoOs=.21bc13d5-dba5-4011-9f16-aae52707d4c0@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <6wOeHEcFHPv0-dg-v19u3S1SNUXTa7FcUJGdrrEFoOs=.21bc13d5-dba5-4011-9f16-aae52707d4c0@github.com>
Message-ID: <em9WZv9vwxx8FgNDIK6-4hpEwz-lxKF9Y00qupHhw-8=.a2e3adff-03fb-4a97-ae92-e7d64cecb1df@github.com>

On Mon, 9 May 2022 09:26:58 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Add a family of "safe" cast methods.
>
> Raffaello Giulietti 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:
> 
>  - 8279986: methods Math::asXExact for safely checked primitive casts
>    
>    Merge branch 'master' into JDK-8279986
>  - 8279986: methods Math::asXExact for safely checked primitive casts
>    
>    Merge branch 'master' into JDK-8279986
>  - 8279986: methods Math::asXExact for safely checked primitive casts
>  - 8279986: methods Math::asXExact for safely checked primitive casts

Post Loom merge

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

PR: https://git.openjdk.java.net/jdk/pull/8548

From simonis at openjdk.java.net  Mon May  9 09:56:19 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 9 May 2022 09:56:19 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v10]
In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
Message-ID: <D0w1dcTNxXKazOefuiDTAy_q-U64OBM2LTr421SpAzw=.a5c9b665-f1f0-43db-bcbe-53b7f59209f8@github.com>

> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
> 
> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
> 
> ### TL;DR
> 
> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
> 
> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
> 
> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
> 
> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*
 k*`]` (where *k* is the number of inflated bytes).
> 
> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).

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

  Updated wording based on @JoeDarcy's third CSR review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7986/files
  - new: https://git.openjdk.java.net/jdk/pull/7986/files/f77b3352..d62cba43

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=08-09

  Stats: 46 lines in 4 files changed: 28 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7986.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7986/head:pull/7986

PR: https://git.openjdk.java.net/jdk/pull/7986

From simonis at openjdk.java.net  Mon May  9 10:05:52 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 9 May 2022 10:05:52 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v10]
In-Reply-To: <D0w1dcTNxXKazOefuiDTAy_q-U64OBM2LTr421SpAzw=.a5c9b665-f1f0-43db-bcbe-53b7f59209f8@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <D0w1dcTNxXKazOefuiDTAy_q-U64OBM2LTr421SpAzw=.a5c9b665-f1f0-43db-bcbe-53b7f59209f8@github.com>
Message-ID: <39OXnEoVqzKr9X8_YcaBTfu8LtcX6emNFFR2FBL4h6I=.9e3504c1-a21a-481c-b84e-e3b898b8aa3d@github.com>

On Mon, 9 May 2022 09:56:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might  write more bytes than the returned number of inflated bytes into the buffer `b`.
>> 
>> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`.
>> 
>> ### TL;DR
>> 
>> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI.
>> 
>> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer.
>> 
>> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit.
>> 
>> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`
 *k*`]` (where *k* is the number of inflated bytes).
>> 
>> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)).
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated wording based on @JoeDarcy's third CSR review

I've uploaded yet another version of this PR based on @jddarcy latest [CSR](https://bugs.openjdk.java.net/browse/JDK-8283758) review. This brings back all the changes to the API documentation of `InflaterInputStream`, `GZipInputStream` and `ZipInputStream` with an additional note in the API doc for `InputStream::read()` which indicates that subclasses of `InputStream` are free to relax the strong requirements imposed by `InputStream::read()`.

Hopefully this version finally gets some consensus :)

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

PR: https://git.openjdk.java.net/jdk/pull/7986

From redestad at openjdk.java.net  Mon May  9 10:12:36 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 9 May 2022 10:12:36 GMT
Subject: RFR: 8286298: Remove unused methods in sun.invoke.util.VerifyType
 [v2]
In-Reply-To: <hm_DCon8SD1b9B3sGDnoRHndjsIU5QKMa2czmHBxRlU=.6a79e0ab-9199-42a8-a69d-183fbfa92cb3@github.com>
References: <hm_DCon8SD1b9B3sGDnoRHndjsIU5QKMa2czmHBxRlU=.6a79e0ab-9199-42a8-a69d-183fbfa92cb3@github.com>
Message-ID: <22fcf7vOlHRzrFLR6F7-O3qrVyAxGUH3GgeGK2CnvXk=.742d56f5-baf0-4e1a-86c7-eabb6144a8a2@github.com>

> A few untested and unused methods in `VerifyType` which can be removed. (Possibly used by native JSR 292 implementations in JDK 7).

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

  Inline isNullReferenceConversion at sole call site and remove it as well

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8570/files
  - new: https://git.openjdk.java.net/jdk/pull/8570/files/a456de4f..b2d1af4b

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

  Stats: 19 lines in 2 files changed: 2 ins; 14 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8570.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8570/head:pull/8570

PR: https://git.openjdk.java.net/jdk/pull/8570

From jvernee at openjdk.java.net  Mon May  9 10:28:27 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 9 May 2022 10:28:27 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
 - Remove unneeded ComputeMoveOrder
 - Remove comment about native calls in lcm.cpp
 - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
   
   Reviewed-by: jvernee, mcimadamore
 - Update riscv and arm stubs
 - Remove spurious ProblemList change
 - Pass pointer to LogStream
 - Polish
 - Replace TraceNativeInvokers flag with unified logging
 - Fix other platforms, take 2
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91

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

Changes: https://git.openjdk.java.net/jdk/pull/7959/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=06
  Stats: 6934 lines in 157 files changed: 2678 ins; 3218 del; 1038 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From alanb at openjdk.java.net  Mon May  9 10:57:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 9 May 2022 10:57:49 GMT
Subject: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v5]
In-Reply-To: <auvx0QlRLQHR8sAjqT1CNXnLRQ6rFPOkLu3JKK31-S0=.0bb3de51-c2ac-46df-b2e9-6b9059e08356@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
 <auvx0QlRLQHR8sAjqT1CNXnLRQ6rFPOkLu3JKK31-S0=.0bb3de51-c2ac-46df-b2e9-6b9059e08356@github.com>
Message-ID: <dx83ghdgzS0u2CKXUmFLoFLoNBckobfWIvmBBMRED58=.b8c05410-bf63-4c6d-b13a-e524b83532d1@github.com>

On Sun, 8 May 2022 12:08:14 GMT, Doug Lea <dl at openjdk.org> wrote:

>> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test improvements

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From dl at openjdk.java.net  Mon May  9 11:13:55 2022
From: dl at openjdk.java.net (Doug Lea)
Date: Mon, 9 May 2022 11:13:55 GMT
Subject: Integrated: 8286294 : ForkJoinPool.commonPool().close() spins
In-Reply-To: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
References: <eKcE2zvFiyhEV62AUoh0fO4aKOwFr_OdimNgGYnVuAo=.f310997d-021e-41fb-83c0-dcb1260cf1d5@github.com>
Message-ID: <_xtqTgi2Hkbm6pvxahoj82-wYpO3lwgtMdMteIt5NgE=.b6661c1f-1dfb-49b4-929d-b2bb8fb38f2d@github.com>

On Fri, 6 May 2022 15:05:57 GMT, Doug Lea <dl at openjdk.org> wrote:

> Changes ForkJoinPool.close spec and code to trap close as a no-op if called on common pool

This pull request has now been integrated.

Changeset: 4f5d73f2
Author:    Doug Lea <dl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4f5d73f2d411aa6147c5388b024e0d2996378d5a
Stats:     120 lines in 3 files changed: 96 ins; 6 del; 18 mod

8286294: ForkJoinPool.commonPool().close() spins

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8577

From itakiguchi at openjdk.java.net  Mon May  9 12:30:19 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 9 May 2022 12:30:19 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v7]
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <LKptirNLwO_uCgREMY_itJbn7mdfKx7pTMq3l7emPnI=.c02a641c-ffab-4594-8a21-5ff203457147@github.com>

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into 8285517
 - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
 - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
 - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
 - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
 - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
 - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

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

Changes: https://git.openjdk.java.net/jdk/pull/8378/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8378&range=06
  Stats: 223 lines in 5 files changed: 213 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8378/head:pull/8378

PR: https://git.openjdk.java.net/jdk/pull/8378

From duke at openjdk.java.net  Mon May  9 12:38:48 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 12:38:48 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v11]
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>

> Hello,
> 
> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
> 
> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
> 
> 
> Greetings
> Raffaello

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

  4511638: Double.toString(double) sometimes produces incorrect results

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3402/files
  - new: https://git.openjdk.java.net/jdk/pull/3402/files/bd323d15..907abfd6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=09-10

  Stats: 30 lines in 2 files changed: 2 ins; 24 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402

PR: https://git.openjdk.java.net/jdk/pull/3402

From duke at openjdk.java.net  Mon May  9 12:38:48 2022
From: duke at openjdk.java.net (limck599)
Date: Mon, 9 May 2022 12:38:48 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v11]
In-Reply-To: <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>
Message-ID: <JDuuPV5lM4UaPp4ZQjJTbupPgG-ecI7Oza7ufSC_MY8=.200e7794-f115-46a3-850c-10cba46dacca@github.com>

On Mon, 9 May 2022 12:34:20 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

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

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

PR: https://git.openjdk.java.net/jdk/pull/3402

From duke at openjdk.java.net  Mon May  9 12:38:53 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 12:38:53 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v10]
In-Reply-To: <-Qu0AFdlNncqx9-RX-1iXm0HwUWBMJesSjyG9HVqrjE=.6a756525-974e-497b-8914-045b3af44862@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <-Qu0AFdlNncqx9-RX-1iXm0HwUWBMJesSjyG9HVqrjE=.6a756525-974e-497b-8914-045b3af44862@github.com>
Message-ID: <nGvSyZj-oTEQy0S59aD01bHTSGc4xXSmwML6i7GUjR8=.6da0740c-3e02-4db5-a58b-3713f92b24ab@github.com>

On Mon, 9 May 2022 09:26:20 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Adapted hashes in ElementStructureTest.java
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Enhanced intervals in MathUtils.
>    Updated references to Schubfach v4.
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Merge branch 'master' into JDK-4511638
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments.
>  - 4511638: Double.toString(double) sometimes produces incorrect results
>    
>    Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/d4474b58...bd323d15

Getting rid of ThreadLocal

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

PR: https://git.openjdk.java.net/jdk/pull/3402

From duke at openjdk.java.net  Mon May  9 12:54:02 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 12:54:02 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v11]
In-Reply-To: <JDuuPV5lM4UaPp4ZQjJTbupPgG-ecI7Oza7ufSC_MY8=.200e7794-f115-46a3-850c-10cba46dacca@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>
 <JDuuPV5lM4UaPp4ZQjJTbupPgG-ecI7Oza7ufSC_MY8=.200e7794-f115-46a3-850c-10cba46dacca@github.com>
Message-ID: <RwZu85T8y4RTeOuKm5lsHUrmltpZsIsJBXvGrcy3rHU=.39605412-e908-490a-98fa-c32cf5895e9b@github.com>

On Mon, 9 May 2022 12:34:20 GMT, limck599 <duke at openjdk.java.net> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   4511638: Double.toString(double) sometimes produces incorrect results
>
> Marked as reviewed by limck599 at github.com (no known OpenJDK username).

@limck599
While we at OpenJDK appreciate constructive reviews from GitHub users not registered in the [census](https://openjdk.java.net/census), only officially nominated reviewers have the authority to approve this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/3402

From jlahoda at openjdk.java.net  Mon May  9 14:18:22 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 9 May 2022 14:18:22 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v10]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <bbC04hW5rMLCNdhlWIB3fQ0NwyhAS4p-ykSkhzlS4_Q=.df141bf2-4cf9-486a-b652-0fcc46f00fe7@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into type-patterns-third
 - Merge branch 'master' into type-patterns-third
 - Reducing MatchException constructors.
 - Merge branch 'master' into type-patterns-third
 - Reference-type pattern is not applicable at a selector of a primitive type - fixing.
 - Merge branch 'master' into type-patterns-third
 - Cleanup, fixing tests.
 - Cleanup - more total -> unconditional pattern renaming.
 - Adjusting to review feedback.
 - Cleanup.
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/4f5d73f2...1101ad46

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

Changes: https://git.openjdk.java.net/jdk/pull/8182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=09
  Stats: 860 lines in 52 files changed: 424 ins; 244 del; 192 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From jlahoda at openjdk.java.net  Mon May  9 14:37:35 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 9 May 2022 14:37:35 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v4]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
 - Using Type.isRaw instead of checking the AST structure.
 - Exhaustiveness should accept supertypes of the specified type.
 - Renaming the features from deconstruction pattern to record pattern.
 - Fixing guards after record patterns.
 - Raw types are not allowed in record patterns.
 - Reflecting review feedback.
 - 8262889: Compiler implementation for Record Patterns

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

Changes: https://git.openjdk.java.net/jdk/pull/8516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=03
  Stats: 2255 lines in 50 files changed: 2169 ins; 15 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From duke at openjdk.java.net  Mon May  9 14:49:44 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 14:49:44 GMT
Subject: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java
 fails with expected [true] but found [false] [v2]
In-Reply-To: <xFy67sI4lu8NWdBi8E8ANi63JLTOA9aMBYwm40BCoQY=.35a1d96b-9dde-48fe-b153-4a2fc70b7372@github.com>
References: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
 <xFy67sI4lu8NWdBi8E8ANi63JLTOA9aMBYwm40BCoQY=.35a1d96b-9dde-48fe-b153-4a2fc70b7372@github.com>
Message-ID: <xyH-jVCSegVHBWJo2aPR58jw4FhCVgiRTXtsV7bOnqw=.5e9bd036-06fe-4f99-9f79-d0019d2898a9@github.com>

On Mon, 9 May 2022 09:25:15 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Please review these small changes to address intermittent failures, as of JDK-8274517.
>> 
>> - Usage of jdk.test.lib.RandomFactory for reproducible random generation.
>> - Slightly less restrictive assertion about badParallelStreamError on L94 (former L88).
>> - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18.
>> 
>> While these changes do not necessarily guarantee absence of intermittent failures, the usage of jdk.test.lib.RandomFactory should at least help to pin down specific double sequences that do not pass the test.
>> 
>> There is still an inherent variability due to the use of parallel streams, though. As double addition is not perfectly associative, even a fully known sequence of doubles may lead to slightly different results with parallelization.
>
> Raffaello Giulietti 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:
> 
>  - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with
>    expected [true] but found [false]
>    
>    Merge branch 'master' into JDK-8274517
>  - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false]

After a post Loom merge, this PR lost its _sponsor_ label, so I had to integrate again.
No changes w.r.t. the previous commit.

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

PR: https://git.openjdk.java.net/jdk/pull/8290

From duke at openjdk.java.net  Mon May  9 14:56:53 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 9 May 2022 14:56:53 GMT
Subject: Integrated: 8274517: java/util/DoubleStreamSums/CompensatedSums.java
 fails with expected [true] but found [false]
In-Reply-To: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
References: <Guvpo8xRMxTfoCol9xOYgbLwzOOGTNVPMsMYx6kfVlQ=.dc4ade86-a83a-442d-9a35-0adfb31c6f13@github.com>
Message-ID: <IizSdT8lzNLajCahO2jSuxwcAnWoalr9sfTEcLz9Gbc=.a08a72f9-8621-43ba-862d-8ca135cd04e7@github.com>

On Tue, 19 Apr 2022 08:40:51 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review these small changes to address intermittent failures, as of JDK-8274517.
> 
> - Usage of jdk.test.lib.RandomFactory for reproducible random generation.
> - Slightly less restrictive assertion about badParallelStreamError on L94 (former L88).
> - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18.
> 
> While these changes do not necessarily guarantee absence of intermittent failures, the usage of jdk.test.lib.RandomFactory should at least help to pin down specific double sequences that do not pass the test.
> 
> There is still an inherent variability due to the use of parallel streams, though. As double addition is not perfectly associative, even a fully known sequence of doubles may lead to slightly different results with parallelization.

This pull request has now been integrated.

Changeset: 97a98352
Author:    Raffaello Giulietti <raffaello.giulietti at oracle.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/97a983526b41d26fcd1caa162a089690119874b0
Stats:     13 lines in 1 file changed: 7 ins; 0 del; 6 mod

8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false]

Reviewed-by: alanb, bpb

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

PR: https://git.openjdk.java.net/jdk/pull/8290

From vromero at openjdk.java.net  Mon May  9 15:12:03 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 9 May 2022 15:12:03 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v4]
In-Reply-To: <ChVux1eet_iKg6KCHWbow6et4Y_XnduA6-JNRWy-zP8=.7d3011a0-d8cb-4f14-a53a-70be44a8db84@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <Z2TvRXQ_wZJSNNUIk9BfBMapIMglj_fxgeMx3e5VQNQ=.52c96e31-0490-4791-964c-475afd40b996@github.com>
 <DPtIa69a2NgNDwSmzHyrn-kQAocDY_j8WoMLhlvrA3w=.846c9409-3838-4605-9ad7-1dfcb435ceba@github.com>
 <ChVux1eet_iKg6KCHWbow6et4Y_XnduA6-JNRWy-zP8=.7d3011a0-d8cb-4f14-a53a-70be44a8db84@github.com>
Message-ID: <bsjqYstjDXx2T5_ihOONXMDx5_3TCqDI4v4HkjjSzck=.47e9b3c4-90fc-43e0-99c5-e585d70446ef@github.com>

On Fri, 6 May 2022 17:40:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4217:
>> 
>>> 4215:         }
>>> 4216:         ListBuffer<BindingSymbol> outBindings = new ListBuffer<>();
>>> 4217:         List<Type> recordTypes = expectedRecordTypes;
>> 
>> nit: probably a matter of style but why not reusing the already declared `expectedRecordTypes` declaring a new variable seems unnecessary
>
> Please note the full `expectedRecordTypes` are used for error reporting, but the reference to `List` in `recordTypes` is overwritten in the loop (at the time of an error report, it may not longer point to the full expected types, and hence cannot be used for error reporting).

Ok I see, thanks

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From vromero at openjdk.java.net  Mon May  9 15:27:53 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 9 May 2022 15:27:53 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v4]
In-Reply-To: <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>
Message-ID: <v5YWR1Sy_z5DmkTixE0MFifEt0Hu_7K7-poD5yKSfhM=.c7b70472-f586-4dd2-b390-dbe30ec20f3f@github.com>

On Mon, 9 May 2022 14:37:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
>  - Using Type.isRaw instead of checking the AST structure.
>  - Exhaustiveness should accept supertypes of the specified type.
>  - Renaming the features from deconstruction pattern to record pattern.
>  - Fixing guards after record patterns.
>  - Raw types are not allowed in record patterns.
>  - Reflecting review feedback.
>  - 8262889: Compiler implementation for Record Patterns

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 822:

> 820:                                                                     nestedComponentPatterns);
> 821: 
> 822:             //for each of the symbols covered by the starting component, find all deconstruction patterns

this comment should probably read: find all `record` patterns?

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From duke at openjdk.java.net  Mon May  9 15:30:53 2022
From: duke at openjdk.java.net (Shruthi)
Date: Mon, 9 May 2022 15:30:53 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v5]
In-Reply-To: <drsenHv3gH1CQqIVvfjj_zFD9oHqZvQQhTJFpWHUAVA=.afcb920c-7236-4aa5-b73a-af3a44f075df@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <drsenHv3gH1CQqIVvfjj_zFD9oHqZvQQhTJFpWHUAVA=.afcb920c-7236-4aa5-b73a-af3a44f075df@github.com>
Message-ID: <YK2TZW9u-K62jAprFwDjnWIkr-ZQfaUzseIL0Gu45vE=.84f0a449-e945-40a8-9df6-a3ea6c577137@github.com>

On Mon, 9 May 2022 07:00:34 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi 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:
> 
>   Add last modified tag

`/integrate`

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From bpb at openjdk.java.net  Mon May  9 15:33:16 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 9 May 2022 15:33:16 GMT
Subject: RFR: 8286363: BigInteger.parallelMultiply missing @since 19
Message-ID: <JssBLeop7k2Zb0XpGI0wT4okV5kJxq1ySkmwJusQAyU=.4923d068-9cf6-4d5e-a1fe-c749e6ab8944@github.com>

Add missing `@since 19` tag.

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

Commit messages:
 - 8286363: BigInteger.parallelMultiply missing @since 19

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

PR: https://git.openjdk.java.net/jdk/pull/8598

From alanb at openjdk.java.net  Mon May  9 15:40:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 9 May 2022 15:40:49 GMT
Subject: RFR: 8286363: BigInteger.parallelMultiply missing @since 19
In-Reply-To: <JssBLeop7k2Zb0XpGI0wT4okV5kJxq1ySkmwJusQAyU=.4923d068-9cf6-4d5e-a1fe-c749e6ab8944@github.com>
References: <JssBLeop7k2Zb0XpGI0wT4okV5kJxq1ySkmwJusQAyU=.4923d068-9cf6-4d5e-a1fe-c749e6ab8944@github.com>
Message-ID: <ETfqUQW4f5namfV7WR8AKGSdH4ysyogDOee7fczANbM=.bdd5e982-a79b-492e-93c5-6591b9cba176@github.com>

On Mon, 9 May 2022 15:26:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add missing `@since 19` tag.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8598

From asotona at openjdk.java.net  Mon May  9 16:05:46 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 9 May 2022 16:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in compound
 assignments
Message-ID: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>

Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.

The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.

The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 

Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.

Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.

Thanks for your review,
Adam

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244681
  Stats: 449 lines in 26 files changed: 444 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From naoto at openjdk.java.net  Mon May  9 16:16:01 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 9 May 2022 16:16:01 GMT
Subject: RFR: 8286163: micro-optimize Instant.plusSeconds
In-Reply-To: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
References: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
Message-ID: <JAFcxohQ10wb1-zj9rTo1FUKzW0v0cLWOuASmc-oAak=.08e1e771-bc80-4e21-97c5-3ef3cbc64838@github.com>

On Wed, 4 May 2022 20:27:04 GMT, lennartfricke <duke at openjdk.java.net> wrote:

> Provide micro-benchmark for comparison

Looks good to me.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8542

From naoto at openjdk.java.net  Mon May  9 16:18:59 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 9 May 2022 16:18:59 GMT
Subject: RFR: 8238373: Punctuation should be same in jlink help usage on
 Japanese language [v2]
In-Reply-To: <7w6P30l41_L74tNKPhy1CTprXvXbn7Zy16XS0SWVckI=.49454ba3-9348-4f7c-9d53-8905d156dad1@github.com>
References: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
 <7w6P30l41_L74tNKPhy1CTprXvXbn7Zy16XS0SWVckI=.49454ba3-9348-4f7c-9d53-8905d156dad1@github.com>
Message-ID: <LPhuW5Yvz4M4i3vfYYVE6KtT5TO2Is76U-mWSPGrvQo=.5061be04-bbb7-4b8b-b27c-5d518cec012e@github.com>

On Mon, 9 May 2022 06:38:29 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

>> When showing help for the jlink command in a Japanese locale, delimiters of option's aliases are a mixture of "," and \u3001. Delimiter should be unified to ",".
>> As the same, there is a inconsistency of delimiters in the jar command help in a Japanese locale, and "," should be used.
>> Similarly, the javap command help uses space as delimiters other than the module option in all locales. This inconsistency should also be corrected.
>> 
>> Would you please review this fix?
>
> KIRIYAMA Takuya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8238373: Punctuation should be same in jlink help usage on Japanese language

I think it's ready for you to integrate. I can sponsor your changes.

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

PR: https://git.openjdk.java.net/jdk/pull/8417

From erikj at openjdk.java.net  Mon May  9 16:33:56 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 9 May 2022 16:33:56 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <QMW2y8ihFHz3GPVQLMACiUV5aGbvwcreUKbGfVwaWGg=.2b5fe22c-6331-4ac2-a05d-44a1b65e85c0@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8599

From darcy at openjdk.java.net  Mon May  9 16:34:57 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 9 May 2022 16:34:57 GMT
Subject: RFR: 8286363: BigInteger.parallelMultiply missing @since 19
In-Reply-To: <JssBLeop7k2Zb0XpGI0wT4okV5kJxq1ySkmwJusQAyU=.4923d068-9cf6-4d5e-a1fe-c749e6ab8944@github.com>
References: <JssBLeop7k2Zb0XpGI0wT4okV5kJxq1ySkmwJusQAyU=.4923d068-9cf6-4d5e-a1fe-c749e6ab8944@github.com>
Message-ID: <N_eH9_8Gg93XKu7ZxDwf0mdcA_DrHFwKc3oqN6MMv64=.3b8ead33-a4e2-4db4-8d38-bdcbd484d09e@github.com>

On Mon, 9 May 2022 15:26:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add missing `@since 19` tag.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8598

From joe.darcy at oracle.com  Mon May  9 16:40:45 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 9 May 2022 09:40:45 -0700
Subject: Why does we still need StrictMath?
In-Reply-To: <230c9947-0da4-a655-fb4e-62748af37286@geomatys.com>
References: <CAJ0GajRAgN=z_e7Ep3Uc=2NC-5L87M8TzhKGYDJ1g6hdzEUEtg@mail.gmail.com>
 <0344c75f-05de-e14a-4a00-15c822cceb61@littlepinkcloud.com>
 <230c9947-0da4-a655-fb4e-62748af37286@geomatys.com>
Message-ID: <58d7d093-6783-b62e-6440-77819b5c24db@oracle.com>

On 5/8/2022 4:10 AM, Martin Desruisseaux wrote:
> Le 08/05/2022 ? 10:56, Andrew Haley a ?crit?:
>
>> Some targets (x86, in particular) have intrinsics (log, trig) that 
>> are faster than StrictMath and also more accurate. StrictMath is not 
>> about accuracy, but cross-architecture down-to-the-last bit 
>> reproducibility. Whether we still need that reproducibility is, I 
>> suppose, something for debate.
>>
> In production code, maybe not. But in test code (e.g. using JUnit), 
> when the program does a lot of trigonometric operations (e.g. map 
> projections), I have meet cases where a test was successful on a 
> machine but failed on another machine. The systematic use of 
> StrictMath in all JUnit test code ensure that the difference in 
> behavior is not in the test code, so we can focus our debugging effort 
> on the main code.

JEP 306 was concerned with changing the definitions of the 
language-level floating-point operations and JVM-level floating-point 
instructions to be consistently strict, the original language and VM 
semantics from the mid-1990's.

The strictfp-ness, or not, of arithmetic operations is a separate matter 
from the semantics of the methods in java.lang.Math and 
java.lang.StrictMath. For example, even when strictfp and default-fp 
were both present, it is was *not* always necessary to declare a method 
in StrictMath to be strictfp (since the difference between strictfp and 
default-fp is only visible when overflow or underflow occurs).

As noted elsewhere in this thread, several platform have faster versions 
of some methods (log, sin, cos, tan, etc.) and in other situations it is 
more expedient to just use the reproducible methods in StrictMath. So to 
meet the reproducibility goals of the platform, StrictMath is still 
needed IMO while Math provides an alternative for users to opt-into 
possible greater speed.

(If Strictmath were being added to the platform today, its specification 
would most likely say the methods need to be correctly rounded, but that 
was less tractable a choice when StrictMath was added in JDK 1.3.)

-Joe


From mcimadamore at openjdk.java.net  Mon May  9 17:41:10 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 May 2022 17:41:10 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v43]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <d9evIGdbRKEMemFle-IujucbpL5NSVC0368hXNf00Lo=.1f918d92-0c6c-4aa8-9ad9-ddc0ac02fe89@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

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

  Fix crashes in heap segment benchmarks due to misaligned access

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7888/files
  - new: https://git.openjdk.java.net/jdk/pull/7888/files/3c88a2ef..7b774297

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=42
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=41-42

  Stats: 41 lines in 2 files changed: 3 ins; 4 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From prr at openjdk.java.net  Mon May  9 17:55:55 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 May 2022 17:55:55 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cih52bus7vW_1tDS7D7szxNTdayfjQxSeHRJhL99DSc=.f5a417b9-844a-4a34-b0b4-8591ac4e28cb@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Marked as reviewed by prr (Reviewer).

test/langtools/tools/javac/lint/LossyConversions.java line 131:

> 129:     @SuppressWarnings("lossy-conversions")
> 130:     public void supressedLossyConversions() {
> 131:         byte a = 0;

you might want to spell suppressed correctly.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From lmesnik at openjdk.java.net  Mon May  9 18:03:01 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 9 May 2022 18:03:01 GMT
Subject: Withdrawn: 8284550: test failure_handler is not properly invoking
 jhsdb jstack, resulting in failure to produce a stack when a test times out
In-Reply-To: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>
References: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>
Message-ID: <J48Ki3JRF6yRgSKz1T8uCeRUGuV_yrI2UiP3UPxC-0c=.5bcaf554-9f54-48e9-908d-5ae7a574b107@github.com>

On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ?resulting in failure to produce a stack when a test times out

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8588

From prr at openjdk.java.net  Mon May  9 18:06:54 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 May 2022 18:06:54 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
Message-ID: <4TPEAEob1ukdLvqdnzddoOBEGrsVfkaQEG5-307Mxjw=.130e42ef-8170-4dcf-bce5-3b69615a6c2a@github.com>

On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust API level to Windows 8 for security.cpp and do some cleanup

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From lmesnik at openjdk.java.net  Mon May  9 18:10:14 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 9 May 2022 18:10:14 GMT
Subject: RFR: 8284980: Test vmTestbase/nsk/stress/except/except010.java times
 out with -Xcomp -XX:+DeoptimizeALot
Message-ID: <hx17CGqJXwggNs0JLwERhxMw5OK6iHhznrjqoOly6yQ=.1e38ef23-f0b7-457c-bb33-7be3a9131732@github.com>

Test executes method recursively and works too long.

It the same issue as [JDK-8139875](https://bugs.openjdk.java.net/browse/JDK-8139875)

The test shouldn't be run with DeoptimizeALot

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

Commit messages:
 - copyrights fixed
 - 8284980: Test vmTestbase/nsk/stress/except/except010.java times out with -Xcomp -XX:+DeoptimizeALot

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

PR: https://git.openjdk.java.net/jdk/pull/8602

From duke at openjdk.java.net  Mon May  9 18:17:00 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Mon, 9 May 2022 18:17:00 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v43]
In-Reply-To: <d9evIGdbRKEMemFle-IujucbpL5NSVC0368hXNf00Lo=.1f918d92-0c6c-4aa8-9ad9-ddc0ac02fe89@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <d9evIGdbRKEMemFle-IujucbpL5NSVC0368hXNf00Lo=.1f918d92-0c6c-4aa8-9ad9-ddc0ac02fe89@github.com>
Message-ID: <qZqy2x12t6QCjaoHVSQgRrsqfXfpEuvjlO-pt1PAB48=.cd926b3f-c75f-493e-8488-69764046c102@github.com>

On Mon, 9 May 2022 17:41:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix crashes in heap segment benchmarks due to misaligned access

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69:

> 67:     static final ValueLayout.OfInt JAVA_INT_UNALIGNED = JAVA_INT.withBitAlignment(8);
> 68:     static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = JAVA_FLOAT.withBitAlignment(8);
> 69:     static final VarHandle intHandleUnaligned = JAVA_INT_UNALIGNED.arrayElementVarHandle();

To?match `LoopOverNonConstantHeap`, this?should?probably be?named `VH_INT_UNALIGNED`.

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

Maybe?these could?also be?moved?into `org.openjdk.bench.java.lang.foreign.Utils`[^1]

[^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From lmesnik at openjdk.java.net  Mon May  9 18:29:57 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 9 May 2022 18:29:57 GMT
Subject: Integrated: 8284550: test failure_handler is not properly invoking
 jhsdb jstack, resulting in failure to produce a stack when a test times out
In-Reply-To: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>
References: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>
Message-ID: <0Kz-7aDguMharRzLo7GFJhkNx3b7RNGGvoCj0EV4of0=.53c26982-b214-4be7-b751-49c4e0a242d9@github.com>

On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ?resulting in failure to produce a stack when a test times out

This pull request has now been integrated.

Changeset: 40470d83
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/40470d83e4d8d4a48eb87e6bf4d221460bddfd75
Stats:     7 lines in 1 file changed: 1 ins; 1 del; 5 mod

8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out

Reviewed-by: dholmes, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8588

From lmesnik at openjdk.java.net  Mon May  9 18:33:38 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 9 May 2022 18:33:38 GMT
Subject: RFR: 8286368: Cleanup problem lists after loom integration
Message-ID: <FGFlG77wBJ_9oPlKFrldqBG_9ixAOGZW6ZHAuEVxkmk=.19ac9767-45f6-4441-89da-66663b9c6e53@github.com>

8286368: Cleanup problem lists after loom integration

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

Commit messages:
 - 8286368: Cleanup problem lists after loom integration

Changes: https://git.openjdk.java.net/jdk/pull/8604/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8604&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286368
  Stats: 27 lines in 4 files changed: 1 ins; 20 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8604.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8604/head:pull/8604

PR: https://git.openjdk.java.net/jdk/pull/8604

From prr at openjdk.java.net  Mon May  9 18:36:59 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 9 May 2022 18:36:59 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <TNi7tutFJLMg6yutpu2AsFme3MkCanqOVXcfb4iSX0A=.431d79e6-1f09-4370-8057-3784d9a6864e@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From mchung at openjdk.java.net  Mon May  9 18:40:56 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 9 May 2022 18:40:56 GMT
Subject: RFR: 8286298: Remove unused methods in sun.invoke.util.VerifyType
 [v2]
In-Reply-To: <22fcf7vOlHRzrFLR6F7-O3qrVyAxGUH3GgeGK2CnvXk=.742d56f5-baf0-4e1a-86c7-eabb6144a8a2@github.com>
References: <hm_DCon8SD1b9B3sGDnoRHndjsIU5QKMa2czmHBxRlU=.6a79e0ab-9199-42a8-a69d-183fbfa92cb3@github.com>
 <22fcf7vOlHRzrFLR6F7-O3qrVyAxGUH3GgeGK2CnvXk=.742d56f5-baf0-4e1a-86c7-eabb6144a8a2@github.com>
Message-ID: <uRXumB24_ovRNZGuDGVe4RyCkSgGemJyHWqWyBIvTv8=.d4fbf156-8d99-4ab8-ab4c-988dbd1ab4bd@github.com>

On Mon, 9 May 2022 10:12:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A few untested and unused methods in `VerifyType` which can be removed. (Possibly used by native JSR 292 implementations in JDK 7).
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inline isNullReferenceConversion at sole call site and remove it as well

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8570

From joehw at openjdk.java.net  Mon May  9 18:56:40 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 9 May 2022 18:56:40 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v5]
In-Reply-To: <drsenHv3gH1CQqIVvfjj_zFD9oHqZvQQhTJFpWHUAVA=.afcb920c-7236-4aa5-b73a-af3a44f075df@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <drsenHv3gH1CQqIVvfjj_zFD9oHqZvQQhTJFpWHUAVA=.afcb920c-7236-4aa5-b73a-af3a44f075df@github.com>
Message-ID: <_-OnTGW0DK6IdPaBEG2Ezuzvj-70rR666rG1dBKB13s=.f44b8852-9274-4dbd-8ea5-6efdfcf70440@github.com>

On Mon, 9 May 2022 07:00:34 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi 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:
> 
>   Add last modified tag

After the last update, the years in the copyright header and LastModified tag do not match. For example, the header for XPATHErrorResources_de.java starts like: Copyright (c) 2019, 2021, where 2021 needs to be updated to 2022. When I mentioned using XPATHErrorResources_ja.java as an example, I meant replacing "reserved comment block" with the copyright header and then update the copyright year. Sorry if I wasn't clear enough. But basically using that as a template for the format of the header, and keep the year updated to the current. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From naoto at openjdk.java.net  Mon May  9 19:07:20 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 9 May 2022 19:07:20 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all
 ZoneOffsets and returns GMT unexpected
Message-ID: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>

This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

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

Commit messages:
 - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

Changes: https://git.openjdk.java.net/jdk/pull/8606/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285844
  Stats: 145 lines in 4 files changed: 98 ins; 1 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

PR: https://git.openjdk.java.net/jdk/pull/8606

From alanb at openjdk.java.net  Mon May  9 19:17:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 9 May 2022 19:17:49 GMT
Subject: RFR: 8286368: Cleanup problem lists after loom integration
In-Reply-To: <FGFlG77wBJ_9oPlKFrldqBG_9ixAOGZW6ZHAuEVxkmk=.19ac9767-45f6-4441-89da-66663b9c6e53@github.com>
References: <FGFlG77wBJ_9oPlKFrldqBG_9ixAOGZW6ZHAuEVxkmk=.19ac9767-45f6-4441-89da-66663b9c6e53@github.com>
Message-ID: <oUKZPWji2F3y-6vdjALicU4TjuJLOdXcp43KHjKIKoE=.8540cea2-8e4d-4815-9fdf-6e5088b449ee@github.com>

On Mon, 9 May 2022 18:17:13 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8286368: Cleanup problem lists after loom integration

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8604

From cjplummer at openjdk.java.net  Mon May  9 19:53:49 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Mon, 9 May 2022 19:53:49 GMT
Subject: RFR: 8284550: test failure_handler is not properly invoking jhsdb
 jstack, resulting in failure to produce a stack when a test times out
In-Reply-To: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>
References: <bXVCBmED7TAfQYwq6UEOGHr5eNtBHMiuppJzpBDBnMQ=.b707ac82-acbc-487a-b09e-8e4cedc71287@github.com>
Message-ID: <AYvZ1D7bCpZ2EDWL4HS3akCQhDkMgj5szQ3zmTDX9Xo=.89ffc29e-acd0-41d2-9656-b9a5a8a054ec@github.com>

On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> ?resulting in failure to produce a stack when a test times out

test/failure_handler/src/share/conf/common.properties line 67:

> 65: 
> 66: jhsdb.app=jhsdb
> 67: jhsdb.jstack.live.args=jstack --mixed --pid %p

What is the plan to address the fact that `--mixed` is not supported on macOS (and produces an error), so on macOS it would be best to leave `--mixed` off so we at least get java stack traces.

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

PR: https://git.openjdk.java.net/jdk/pull/8588

From darcy at openjdk.java.net  Mon May  9 20:26:56 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 9 May 2022 20:26:56 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <8O_QfMi1b_fhddBS7yzm9cwzf-l6nWbfNs6qFJWdtuU=.22f44b80-54e8-4249-8ece-d02be29f4267@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

I see there is already a bug filed to address situations found by the new warning in the JDK's libraries (JDK-8286374). As a matter of policy, I recommend the (potential) warnings be addressed in at least the java.base and java.desktop modules before the new warning is enabled. In other words, a priority should be given to keeping java.base and java.desktop compiling successfully with all warnings enabled.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From mcimadamore at openjdk.java.net  Mon May  9 20:30:09 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 May 2022 20:30:09 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v43]
In-Reply-To: <qZqy2x12t6QCjaoHVSQgRrsqfXfpEuvjlO-pt1PAB48=.cd926b3f-c75f-493e-8488-69764046c102@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <d9evIGdbRKEMemFle-IujucbpL5NSVC0368hXNf00Lo=.1f918d92-0c6c-4aa8-9ad9-ddc0ac02fe89@github.com>
 <qZqy2x12t6QCjaoHVSQgRrsqfXfpEuvjlO-pt1PAB48=.cd926b3f-c75f-493e-8488-69764046c102@github.com>
Message-ID: <Zjv5MbxQTerqGoIscFVqnSaHxjpN82zi8cDGexD74Ng=.7391bdff-3fc3-49d9-ad79-da05ae8d9ce1@github.com>

On Mon, 9 May 2022 18:09:51 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix crashes in heap segment benchmarks due to misaligned access
>
> test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69:
> 
>> 67:     static final ValueLayout.OfInt JAVA_INT_UNALIGNED = JAVA_INT.withBitAlignment(8);
>> 68:     static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = JAVA_FLOAT.withBitAlignment(8);
>> 69:     static final VarHandle intHandleUnaligned = JAVA_INT_UNALIGNED.arrayElementVarHandle();
> 
> To?match `LoopOverNonConstantHeap`, this?should?probably be?named `VH_INT_UNALIGNED`.
> 
> --------------------------------------------------------------------------------
> 
> Maybe?these could?also be?moved?into `org.openjdk.bench.java.lang.foreign.Utils`[^1]
> 
> [^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43

I noted other possible cleanups for benchmarks, I'll work on something after we integrate this PR as I'd like to minimize the churn.

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

PR: https://git.openjdk.java.net/jdk/pull/7888

From lmesnik at openjdk.java.net  Mon May  9 20:43:11 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 9 May 2022 20:43:11 GMT
Subject: RFR: 8286438: Add jhsdb jstack processing without --mixed in efh
Message-ID: <Gg3kYyHr2FVU5WMmrsfRhjB_3z-0-QyOvUMU4rO43oQ=.5cb2a8ad-c943-4ae2-a2c7-385fa197ce5a@github.com>

The default is required only to set the same depth level in the tree on HTML page for default and mixed mode.

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

Commit messages:
 - 8286438: Add jhsdb jstack processing without --mixed in efh

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

PR: https://git.openjdk.java.net/jdk/pull/8610

From vromero at openjdk.java.net  Mon May  9 20:55:55 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 9 May 2022 20:55:55 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v4]
In-Reply-To: <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>
Message-ID: <p5A-Gz5Und0__YFKtbfHdrf7ryMiUXhLcOTfErMlc3M=.78efa499-486c-40a6-b139-706476c9eab3@github.com>

On Mon, 9 May 2022 14:37:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
>  - Using Type.isRaw instead of checking the AST structure.
>  - Exhaustiveness should accept supertypes of the specified type.
>  - Renaming the features from deconstruction pattern to record pattern.
>  - Fixing guards after record patterns.
>  - Raw types are not allowed in record patterns.
>  - Reflecting review feedback.
>  - 8262889: Compiler implementation for Record Patterns

I've noticed that this code:

class Test {
    String e(E e) {
        return switch (e) {
            case A -> "42";
        };
    }

    enum E {
        A, B;
    }
}

fails with:

Test.java:3: error: the switch expression does not cover all possible input values
        return switch (e) {
               ^
1 error

before this change but gets accepted with no error message after it

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From asemenyuk at openjdk.java.net  Mon May  9 21:36:21 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 9 May 2022 21:36:21 GMT
Subject: RFR: 8282351: jpackage does not work if class file has `$$` in the
 name on windows
Message-ID: <a352QUpC1ImT0wbU98l8LDXy-qI3W4vRzvkCY51Hv0E=.ea1b6c01-8d60-492e-bc9e-01881e8edeb2@github.com>

8282351: jpackage does not work if class file has `$$` in the name on windows

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

Commit messages:
 - Fix regression
 - 8282351: jpackage does not work if class file has `$$` in the name on windows

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

PR: https://git.openjdk.java.net/jdk/pull/8613

From rafael.wth at gmail.com  Mon May  9 21:43:49 2022
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Mon, 9 May 2022 23:43:49 +0200
Subject: HttpClient has no explicit way of releasing threads
Message-ID: <CA+DM0AmX9edJxK4Hv5NCsaFh7k4TouQhgmfTsCJg2_NquLCzWw@mail.gmail.com>

Hello,

looking at thread dumps, I realized that the HttpClient implementation does
not offer an explicit way to release its threads. Currently, the client:

1. maintains a cached thread pool with a retention size of 60 seconds. If
many such clients are created for short lived application, these threads
pile up.
2. has a selector thread that only shuts down if the outer "facade"
reference is collected via a weak reference. If an application is not
running GC, this can take a while.

This is not a big problem but I have seen peaks with suddenly many, many
threads (in test code) where many HttpClients were created for single use
and I was wondering if it was ever considered to add a method for disposing
the threads explicitly?

Alternatively, it might be an option to add a method like
HttpClient.shared() which would return a singleton HttpClient (created on
the first call, collected if no reference is kept anymore but reused in the
meantime) to address such scenarios. I can of course add a singleton in my
test project but I find this a bit awkward as it is something to remember
and to repeat in all applications we maintain. Therefore, it might be
convenient to add such methods for tests that usually aim to be decoupled.

Thanks for your consideration,
best regards, Rafael

From psandoz at openjdk.java.net  Mon May  9 21:58:54 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 9 May 2022 21:58:54 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
Message-ID: <PAbHd6tldh6Is0PsXN3l5gzVGugeU9aXERzFEdFOWCE=.c19b875b-50ec-4c08-a75d-cd23d27e2bfa@github.com>

On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename "use_predicate" to "needs_predicate"

I did modified the code of this PR to avoid the conversion of `boolean` to `int` and the masked load is made intrinsic from the method at which the constants are passed as arguments i.e. the public `fromArray` mask accepting method.

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From almatvee at openjdk.java.net  Mon May  9 22:12:49 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 9 May 2022 22:12:49 GMT
Subject: RFR: 8282351: jpackage does not work if class file has `$$` in the
 name on windows
In-Reply-To: <a352QUpC1ImT0wbU98l8LDXy-qI3W4vRzvkCY51Hv0E=.ea1b6c01-8d60-492e-bc9e-01881e8edeb2@github.com>
References: <a352QUpC1ImT0wbU98l8LDXy-qI3W4vRzvkCY51Hv0E=.ea1b6c01-8d60-492e-bc9e-01881e8edeb2@github.com>
Message-ID: <tGlomX9Mb2xNUX7HNEkuowvl3ZweOGZDfoVPKFruA5k=.0f2820e6-68b4-418e-88cf-24c4b9ff6c04@github.com>

On Mon, 9 May 2022 21:25:37 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8282351: jpackage does not work if class file has `$$` in the name on windows

Marked as reviewed by almatvee (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8613

From clanger at openjdk.java.net  Mon May  9 22:18:11 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 9 May 2022 22:18:11 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful enough to
 find root cause
Message-ID: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>

After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
contains jar files with . or .. in its name. The error message, however, does not help to find
the culprit. This could be improved.

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

Commit messages:
 - JDK-8286444

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From clanger at openjdk.java.net  Mon May  9 22:36:51 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 9 May 2022 22:36:51 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
Message-ID: <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>

On Mon, 9 May 2022 22:10:54 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
> contains jar files with . or .. in its name. The error message, however, does not help to find
> the culprit. This could be improved.

@LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From uschindler at openjdk.java.net  Mon May  9 22:44:58 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Mon, 9 May 2022 22:44:58 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected
In-Reply-To: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
Message-ID: <ABcvJDzCIRi4XaSaASXbB8fxcJXuyIODjxGO5J9oh0E=.7c7c2beb-bd96-4982-99e0-e19e5d4b2979@github.com>

On Mon, 9 May 2022 18:59:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

Marked as reviewed by uschindler (Author).

src/java.base/share/classes/java/util/TimeZone.java line 539:

> 537:     public static TimeZone getTimeZone(ZoneId zoneId) {
> 538:         String tzid = zoneId.getId(); // throws an NPE if null
> 539:         if (zoneId instanceof ZoneOffset zo) {

I like this because it is much faster than the conversion to ZoneId and parsing it back! It is similar to use of SimpleTimeZone, but this is better as the returned timezone is unmodifiable, correct?

test/jdk/java/util/TimeZone/ZoneOffsetRoundTripTest.java line 43:

> 41:     private Object[][] testZoneOffsets() {
> 42:         return new Object[][] {
> 43:                 {ZoneId.of("Z"), 0},

I know, `ZoneId.of()` should parse this as a `ZoneOffset` and return a `ZoneOffset` instance, but maybe add also the other string variants with prefix (`ZoneId.of("UTC+00:00:01")` or `ZoneId.of("GMT+00:00:01")` as data items. Maybe also use `ZoneOffset.of()` for the plain zones to be explicit.

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

PR: https://git.openjdk.java.net/jdk/pull/8606

From lmesnik at openjdk.java.net  Tue May 10 00:16:27 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 10 May 2022 00:16:27 GMT
Subject: RFR: 8284980: Test vmTestbase/nsk/stress/except/except010.java
 times out with -Xcomp -XX:+DeoptimizeALot [v2]
In-Reply-To: <hx17CGqJXwggNs0JLwERhxMw5OK6iHhznrjqoOly6yQ=.1e38ef23-f0b7-457c-bb33-7be3a9131732@github.com>
References: <hx17CGqJXwggNs0JLwERhxMw5OK6iHhznrjqoOly6yQ=.1e38ef23-f0b7-457c-bb33-7be3a9131732@github.com>
Message-ID: <KoRj22Q3PpFgGS72cBbyCLfdLeIuk2oBf3-Dvv01F5w=.3e3adf4c-ec77-43de-9e2a-20a698d7c4eb@github.com>

> Test executes method recursively and works too long.
> 
> It the same issue as [JDK-8139875](https://bugs.openjdk.java.net/browse/JDK-8139875)
> 
> The test shouldn't be run with DeoptimizeALot

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

  Rename Read2.jav` to Read2.java
  
  reverted renaming

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8602/files
  - new: https://git.openjdk.java.net/jdk/pull/8602/files/84a75c5c..900deb58

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

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8602.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8602/head:pull/8602

PR: https://git.openjdk.java.net/jdk/pull/8602

From xgong at openjdk.java.net  Tue May 10 01:20:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 10 May 2022 01:20:40 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <PAbHd6tldh6Is0PsXN3l5gzVGugeU9aXERzFEdFOWCE=.c19b875b-50ec-4c08-a75d-cd23d27e2bfa@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <PAbHd6tldh6Is0PsXN3l5gzVGugeU9aXERzFEdFOWCE=.c19b875b-50ec-4c08-a75d-cd23d27e2bfa@github.com>
Message-ID: <_QEcTANm1mniixGLtt_oJ7O97TbPRriNKizi6MCViiM=.70b10358-a8ae-440a-a3a2-ff0fefd3d0b3@github.com>

On Mon, 9 May 2022 21:55:27 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I modified the code of this PR to avoid the conversion of `boolean` to `int`, so a constant integer value is passed all the way through, and the masked load is made intrinsic from the method at which the constants are passed as arguments i.e. the public `fromArray` mask accepting method.

Great and thanks! Could you please show me the changes or an example? I can push the changes to this PR. Thanks so much!

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Tue May 10 01:30:13 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 10 May 2022 01:30:13 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if offset
 is out of array boundary for masked store
Message-ID: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>

Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.

The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:

Benchmark                                   Before    After     Gain Units
StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms

Similar performane gain can also be observed on ARM hardware.

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

Commit messages:
 - 8286279: [vectorapi] Only check index of masked lanes if offset is out of array boundary for masked store

Changes: https://git.openjdk.java.net/jdk/pull/8620/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8620&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286279
  Stats: 213 lines in 8 files changed: 188 ins; 0 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8620.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8620/head:pull/8620

PR: https://git.openjdk.java.net/jdk/pull/8620

From asemenyuk at openjdk.java.net  Tue May 10 02:56:49 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 10 May 2022 02:56:49 GMT
Subject: Integrated: 8282351: jpackage does not work if class file has `$$` in
 the name on windows
In-Reply-To: <a352QUpC1ImT0wbU98l8LDXy-qI3W4vRzvkCY51Hv0E=.ea1b6c01-8d60-492e-bc9e-01881e8edeb2@github.com>
References: <a352QUpC1ImT0wbU98l8LDXy-qI3W4vRzvkCY51Hv0E=.ea1b6c01-8d60-492e-bc9e-01881e8edeb2@github.com>
Message-ID: <gHIaUpKJ3jAlfwPhjQCqCEGtgQlaG0g_m9Ee0-RGfbY=.3cfafe62-4516-4d38-93a6-3b0e76ea1f82@github.com>

On Mon, 9 May 2022 21:25:37 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8282351: jpackage does not work if class file has `$$` in the name on windows

This pull request has now been integrated.

Changeset: 29395534
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/29395534d9683a802364dc53610dee2b525fb032
Stats:     180 lines in 2 files changed: 178 ins; 0 del; 2 mod

8282351: jpackage does not work if class file has `$$` in the name on windows

Reviewed-by: almatvee

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

PR: https://git.openjdk.java.net/jdk/pull/8613

From darcy at openjdk.java.net  Tue May 10 03:26:51 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 10 May 2022 03:26:51 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v11]
In-Reply-To: <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>
Message-ID: <UkougCywkC6YSJeQRa0G5TCY6H8xZheWyGpZwLUCyqM=.6b53d8f9-b0f8-470b-bfec-368056d706bf@github.com>

On Mon, 9 May 2022 12:38:48 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

Generally looks solid!

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 882:

> 880:         try {
> 881:             FloatToDecimal.appendTo(f, this);
> 882:         } catch (IOException ignored) {

What is the motivation for wrapping with IOException?

src/java.base/share/classes/java/lang/Double.java line 33:

> 31: import java.util.Optional;
> 32: 
> 33: import jdk.internal.math.FloatingDecimal;

Presumably the FloatingDecimal import here and in Float can be removed.

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 38:

> 36:  * This class exposes a method to render a {@code double} as a string.
> 37:  *
> 38:  * @author Raffaello Giulietti

New code shouldn't use author tags.

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

PR: https://git.openjdk.java.net/jdk/pull/3402

From iklam at openjdk.java.net  Tue May 10 04:09:57 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 10 May 2022 04:09:57 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
Message-ID: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>

The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.

It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.

I also cleaned up related code in the JDK and HotSpot.

Testing:
- Passed tiers 1 and 2
- Tiers 3, 4, 5 are in progress

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

Commit messages:
 - 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

Changes: https://git.openjdk.java.net/jdk/pull/8622/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8622&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286441
  Stats: 193 lines in 15 files changed: 0 ins; 144 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8622.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8622/head:pull/8622

PR: https://git.openjdk.java.net/jdk/pull/8622

From darcy at openjdk.java.net  Tue May 10 04:45:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 10 May 2022 04:45:42 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v2]
In-Reply-To: <6wOeHEcFHPv0-dg-v19u3S1SNUXTa7FcUJGdrrEFoOs=.21bc13d5-dba5-4011-9f16-aae52707d4c0@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <6wOeHEcFHPv0-dg-v19u3S1SNUXTa7FcUJGdrrEFoOs=.21bc13d5-dba5-4011-9f16-aae52707d4c0@github.com>
Message-ID: <2dY3mGc0yxKMCvVTzM-HRNJkS0EBQopGwYeOJ955Zs8=.1de84afe-d76f-4c86-b0f0-c7a1b6dcca0c@github.com>

On Mon, 9 May 2022 09:26:58 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Add a family of "safe" cast methods.
>
> Raffaello Giulietti 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:
> 
>  - 8279986: methods Math::asXExact for safely checked primitive casts
>    
>    Merge branch 'master' into JDK-8279986
>  - 8279986: methods Math::asXExact for safely checked primitive casts
>    
>    Merge branch 'master' into JDK-8279986
>  - 8279986: methods Math::asXExact for safely checked primitive casts
>  - 8279986: methods Math::asXExact for safely checked primitive casts

src/java.base/share/classes/java/lang/Math.java line 1367:

> 1365:      * Returns the value of the {@code double} argument,
> 1366:      * throwing an exception if the conversion is inexact.
> 1367:      * The method returns iff the argument and the result

Style suggestion: given the audience of the javadoc, rather than "iff" write out "if and only if" or other full word construct.

src/java.base/share/classes/java/lang/Math.java line 1578:

> 1576:      */
> 1577:     @ForceInline
> 1578:     public static long toUnsignedIntExact(long value) {

Existing methods like Integer.parseUnsignedInt interpret the negative int values as positive values larger than MAX_INT. So if an int is not going to be returned here, I suggest a name like "toUnsignedIntRangeExact".

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

PR: https://git.openjdk.java.net/jdk/pull/8548

From alanb at openjdk.java.net  Tue May 10 05:46:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 05:46:40 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
Message-ID: <sP56z9aywPoeUIffZeFzRQMn1z2QN14vH9E60_jS894=.5561b038-da1f-46ba-9835-bdf3694759e7@github.com>

On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust API level to Windows 8 for security.cpp and do some cleanup

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From mbaesken at openjdk.java.net  Tue May 10 06:48:40 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 10 May 2022 06:48:40 GMT
Subject: Integrated: JDK-8285730: unify _WIN32_WINNT settings
In-Reply-To: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
Message-ID: <b3VPZzv5rMrCbK3rKJwOGCOui9QWYxkVkmtID9wAOlw=.4abdd258-c73d-4420-b15a-e644f4cd1328@github.com>

On Wed, 27 Apr 2022 14:57:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
> Macros for Conditional Declarations
> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
> 
> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).

This pull request has now been integrated.

Changeset: 4fd79a6a
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4fd79a6ad2683e4863bd4e311cb01cbc30ebf57f
Stats:     33 lines in 7 files changed: 2 ins; 25 del; 6 mod

8285730: unify _WIN32_WINNT settings

Reviewed-by: dholmes, erikj, ihse, prr, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8428

From duke at openjdk.java.net  Tue May 10 06:52:00 2022
From: duke at openjdk.java.net (Shruthi)
Date: Tue, 10 May 2022 06:52:00 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v6]
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <EEovBYT0vNoGAm-jZeelZrHUTwQKBVx8lFqEHI37cr0=.5f40c591-a9a3-452c-acdf-31c001b083be@github.com>

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

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

  update copyright header

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8318/files
  - new: https://git.openjdk.java.net/jdk/pull/8318/files/b1dcd44c..0cf1f9b9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=04-05

  Stats: 17 lines in 10 files changed: 0 ins; 7 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8318/head:pull/8318

PR: https://git.openjdk.java.net/jdk/pull/8318

From mbaesken at openjdk.java.net  Tue May 10 07:46:13 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 10 May 2022 07:46:13 GMT
Subject: RFR: 8286191: misc tests fail due to JDK-8285987 [v4]
In-Reply-To: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
References: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
Message-ID: <e9PNWt-a99NJp7rA-I_bjEsWBp5Yba-XSTctcXcEj-Q=.77cb286f-eb1c-4f85-89f2-e2451342ac39@github.com>

> The isMusl method had to be handled in test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools tests.

Matthias Baesken 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 six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8286191
 - restore year in ExternalEditorTest, remove test exclusion
 - Merge remote-tracking branch 'origin/master' into JDK-8286191
 - remove from ProblemList
 - Merge remote-tracking branch 'origin/master' into JDK-8286191
 - JDK-8286191

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8556/files
  - new: https://git.openjdk.java.net/jdk/pull/8556/files/2337301c..4c9e5b7e

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

  Stats: 104552 lines in 1272 files changed: 94955 ins; 4519 del; 5078 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8556.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8556/head:pull/8556

PR: https://git.openjdk.java.net/jdk/pull/8556

From mbaesken at openjdk.java.net  Tue May 10 07:47:26 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 10 May 2022 07:47:26 GMT
Subject: Integrated: 8286191: misc tests fail due to JDK-8285987
In-Reply-To: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
References: <DSWI6c_RloGAXVO5UjRJsPc49E8kFl6kxXTjPj0Uecg=.2ad73424-1413-4e93-8187-815852284b33@github.com>
Message-ID: <IDSwEO0riVpNkwnZOqvM1rpfcxzaZ9ZoCCzdsr-sSTg=.d0f735a3-6471-494c-b8b3-79db4bb5602b@github.com>

On Thu, 5 May 2022 15:21:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The isMusl method had to be handled in test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java .
> Additionally, the vm.musl predicate seem not to be available in the langtools tests.

This pull request has now been integrated.

Changeset: de8f4d01
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/de8f4d01b234f5224a687dae5db52ab31247c2da
Stats:     6 lines in 4 files changed: 0 ins; 4 del; 2 mod

8286191: misc tests fail due to JDK-8285987

Reviewed-by: rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/8556

From asotona at openjdk.java.net  Tue May 10 08:46:45 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 10 May 2022 08:46:45 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <oWxFgbGHRAk_wFpGtPGtfrAlzLUVXctQCCRZ9pi43Mg=.ee995996-668b-4509-98c0-76337a2f9818@github.com>

On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

I agree with the priority to keep java.base and java.desktop clean from possibly lossy conversions, so the related issues should probably raise from P4 priority level.

However this lint warning as a part of the javac is critical to confirm that the situations have been correctly addressed.
If we want to avoid "blind" patching, we only two possible scenarios:
1. big homogenous patch including hundreds of fixed lines of code across many "moving-target" classes, together with lint warning implemented and enabled 
2. javac lint patch (disabled for affected JDK modules build) goes first, so each case can be resolved, reviewed and validated in individual patch 

>From complexity and cost perspective I prefer the second scenario.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From redestad at openjdk.java.net  Tue May 10 09:02:59 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 10 May 2022 09:02:59 GMT
Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to
 reduce allocation pressure [v2]
In-Reply-To: <mWNCEl3SGAnUluIIw9IZVtzwFcQAuOfJlzylwZ3s2tE=.58bc7b09-ecd3-491a-8a85-9195ba52ae32@github.com>
References: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
 <mWNCEl3SGAnUluIIw9IZVtzwFcQAuOfJlzylwZ3s2tE=.58bc7b09-ecd3-491a-8a85-9195ba52ae32@github.com>
Message-ID: <3O3zJ2NPOFO705uA7FcgD5b7IxoTYk49WIFXppKrdkc=.8b9e04ce-2739-41c0-9d3c-93770fcf8e6b@github.com>

On Wed, 4 May 2022 09:46:00 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282701: Revert some irrelevant changes

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7714

From duke at openjdk.java.net  Tue May 10 09:04:00 2022
From: duke at openjdk.java.net (lennartfricke)
Date: Tue, 10 May 2022 09:04:00 GMT
Subject: Integrated: 8286163: micro-optimize Instant.plusSeconds
In-Reply-To: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
References: <FS3ZxZIgzDppOjKF_GGF6pl7Mp0Dd_L57XCH86lVYS0=.4854e82b-0700-41b4-abcb-60c8246fd0c1@github.com>
Message-ID: <5WefhkrvMmtmqjxBhaIrGfDk4wgfP7Y_xpp1YGpvHnQ=.ee5b0464-b7a3-429c-8cd3-0fdb79098cff@github.com>

On Wed, 4 May 2022 20:27:04 GMT, lennartfricke <duke at openjdk.java.net> wrote:

> Provide micro-benchmark for comparison

This pull request has now been integrated.

Changeset: 34621909
Author:    Lennart Fricke <lennart.fricke at drehpunkt.de>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3462190965befc07fc79202b688887f7927fc856
Stats:     94 lines in 2 files changed: 93 ins; 0 del; 1 mod

8286163: micro-optimize Instant.plusSeconds

Reviewed-by: scolebourne, redestad, naoto

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

PR: https://git.openjdk.java.net/jdk/pull/8542

From redestad at openjdk.java.net  Tue May 10 09:06:52 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 10 May 2022 09:06:52 GMT
Subject: Integrated: 8286298: Remove unused methods in
 sun.invoke.util.VerifyType
In-Reply-To: <hm_DCon8SD1b9B3sGDnoRHndjsIU5QKMa2czmHBxRlU=.6a79e0ab-9199-42a8-a69d-183fbfa92cb3@github.com>
References: <hm_DCon8SD1b9B3sGDnoRHndjsIU5QKMa2czmHBxRlU=.6a79e0ab-9199-42a8-a69d-183fbfa92cb3@github.com>
Message-ID: <-A7dtxHklLWUfCzpC5TaNe8Zxy7L0q2SkemUDQk1lkM=.49fff20a-b19e-4eb8-92c7-1805551247df@github.com>

On Fri, 6 May 2022 11:32:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A few untested and unused methods in `VerifyType` which can be removed. (Possibly used by native JSR 292 implementations in JDK 7).

This pull request has now been integrated.

Changeset: 3fa1c404
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3fa1c4043919943baf0a2cdfaf040ffdd844750c
Stats:     91 lines in 2 files changed: 2 ins; 85 del; 4 mod

8286298: Remove unused methods in sun.invoke.util.VerifyType

Reviewed-by: bpb, alanb, mchung

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

PR: https://git.openjdk.java.net/jdk/pull/8570

From asotona at openjdk.java.net  Tue May 10 09:07:44 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 10 May 2022 09:07:44 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v2]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

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

  8244681: Add a warning for possibly lossy conversion in compound assignments
  recommended correction of the warning wording
  fixed typo in test method name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/47779ba5..6b3942b8

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

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From jlahoda at openjdk.java.net  Tue May 10 09:57:48 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 10 May 2022 09:57:48 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v5]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <MYQYuhBdAWz5laM3hVrIlVC7KJQE38AJ-Y-lPbw-mP0=.ef02fbe6-bfc5-49e0-8e30-712c187b0f6c@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

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

  Fixing (non-)exhaustiveness for enum.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8516/files
  - new: https://git.openjdk.java.net/jdk/pull/8516/files/10cd9d0c..a0d0c78b

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

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlahoda at openjdk.java.net  Tue May 10 09:57:48 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 10 May 2022 09:57:48 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v4]
In-Reply-To: <p5A-Gz5Und0__YFKtbfHdrf7ryMiUXhLcOTfErMlc3M=.78efa499-486c-40a6-b139-706476c9eab3@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <X25w3rL0sC8vJopiaHbf3g82rQHhcATLJGuig8TvfOI=.7aa5976c-8b57-41cd-af61-7dfff755cbfe@github.com>
 <p5A-Gz5Und0__YFKtbfHdrf7ryMiUXhLcOTfErMlc3M=.78efa499-486c-40a6-b139-706476c9eab3@github.com>
Message-ID: <fWHS3ZY89choXUb8cVVyTiwFTLayaz8DaXObUWXQ5WA=.cf10a3a9-ef5e-44fb-9673-2a4df7a09746@github.com>

On Mon, 9 May 2022 20:52:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I've noticed that this code:
> 
> ```
> class Test {
>     String e(E e) {
>         return switch (e) {
>             case A -> "42";
>         };
>     }
> 
>     enum E {
>         A, B;
>     }
> }
> ```
> 
> fails with:
> 
> ```
> Test.java:3: error: the switch expression does not cover all possible input values
>         return switch (e) {
>                ^
> 1 error
> ```
> 
> before this change but gets accepted with no errors after the change in this PR

Oops, sorry, should be fixed now ([a0d0c78](https://github.com/openjdk/jdk/pull/8516/commits/a0d0c78bcbb5ecb010c2e9bd235b3ae89eb00823)).

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

PR: https://git.openjdk.java.net/jdk/pull/8516

From dfuchs at openjdk.java.net  Tue May 10 11:16:48 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 10 May 2022 11:16:48 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230:

> 228:         List<SubRegistry> l = new ArrayList<>();
> 229:         for (Class<?> c : categoryMap.keySet()) {
> 230:             if (c.isInstance(provider)) {

Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE.

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From aturbanov at openjdk.java.net  Tue May 10 11:35:04 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 10 May 2022 11:35:04 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
 <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>
Message-ID: <iyPHYWiIL0mqxp3iaAaDT3pMp6tFWEpERqLGJ2sgiao=.1f3e0af5-0d64-4769-9282-c120201fe5e0@github.com>

On Tue, 10 May 2022 11:10:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>>   apply suggestion to avoid second Method.invoke call
>
> src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230:
> 
>> 228:         List<SubRegistry> l = new ArrayList<>();
>> 229:         for (Class<?> c : categoryMap.keySet()) {
>> 230:             if (c.isInstance(provider)) {
> 
> Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE.

No. This method is called from 3 places,  and there 3 null checks before the method call.

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From daniel.fuchs at oracle.com  Tue May 10 11:36:57 2022
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 10 May 2022 12:36:57 +0100
Subject: HttpClient has no explicit way of releasing threads
In-Reply-To: <CA+DM0AmX9edJxK4Hv5NCsaFh7k4TouQhgmfTsCJg2_NquLCzWw@mail.gmail.com>
References: <CA+DM0AmX9edJxK4Hv5NCsaFh7k4TouQhgmfTsCJg2_NquLCzWw@mail.gmail.com>
Message-ID: <8a5f39ba-064f-2aa8-4744-818c7d3ee7cf@oracle.com>

Hi Rafael,

On 09/05/2022 22:43, Rafael Winterhalter wrote:
> Hello,
> 
> looking at thread dumps, I realized that the HttpClient implementation does
> not offer an explicit way to release its threads. Currently, the client:
> 
> 1. maintains a cached thread pool with a retention size of 60 seconds. If
> many such clients are created for short lived application, these threads
> pile up.
> 2. has a selector thread that only shuts down if the outer "facade"
> reference is collected via a weak reference. If an application is not
> running GC, this can take a while.
> 
> This is not a big problem but I have seen peaks with suddenly many, many
> threads (in test code) where many HttpClients were created for single use
> and I was wondering if it was ever considered to add a method for disposing
> the threads explicitly?

I would consider it bad practice to create an HttpClient instance for
single usage; Ideally a client should be reused - provided that
the security context is the same. Creating an HttpClient involves
creating a thread pool, a selector, a selector manager thread,
potentially initializing an SSL context etc...

WRT to adding a method for disposing the HttpClient explicitly, then
yes - that's something that we could consider for a major
release. It would need to be carefully specified - especially WRT what
would be the effect of calling this method if some operations are still
in progress. Asynchronously closing objects that are still in use is
a notoriously thorny subject.
We might need something equivalent to what is defined for executor
services - that is - one variant that waits for all ongoing operations
to terminate before closing, and one that abruptly aborts any
on-going operation.

> Alternatively, it might be an option to add a method like
> HttpClient.shared() which would return a singleton HttpClient (created on
> the first call, collected if no reference is kept anymore but reused in the
> meantime) to address such scenarios. I can of course add a singleton in my
> test project but I find this a bit awkward as it is something to remember
> and to repeat in all applications we maintain. Therefore, it might be
> convenient to add such methods for tests that usually aim to be decoupled.

An HttpClient is a kind of capability object so I don't think we want
to have a shared client in the Java API. That's something that
an application can easily implement at the application level if it
makes sense for the application.

A possibility to work around the thread peak issue is also for an
application to configure its own thread executor on the HttpClient.
If that makes sense for the application and if it is safe to do
so the executor can also be shared between several client.
It is then the responsibility of the application
to shutdown the executor when the clients are no longer in use.

> 
> Thanks for your consideration,
> best regards, Rafael

best regards,

-- daniel

From dfuchs at openjdk.java.net  Tue May 10 11:43:55 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 10 May 2022 11:43:55 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <iyPHYWiIL0mqxp3iaAaDT3pMp6tFWEpERqLGJ2sgiao=.1f3e0af5-0d64-4769-9282-c120201fe5e0@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
 <RYNCwh7eHPTdYusU_PAZuvo0BIPXlrWbs7ppxq-1UjQ=.59650d85-491d-4509-b212-f694ef6afd94@github.com>
 <iyPHYWiIL0mqxp3iaAaDT3pMp6tFWEpERqLGJ2sgiao=.1f3e0af5-0d64-4769-9282-c120201fe5e0@github.com>
Message-ID: <endEBOSOYQDoktP2AgDxXQDJK6XpeuHGvgATOffZHmo=.9635df10-a2c3-40be-81ea-aa4ffc80bdcb@github.com>

On Tue, 10 May 2022 11:31:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java line 230:
>> 
>>> 228:         List<SubRegistry> l = new ArrayList<>();
>>> 229:         for (Class<?> c : categoryMap.keySet()) {
>>> 230:             if (c.isInstance(provider)) {
>> 
>> Can this be reached if `provider` is null? If yes there could be a change of behaviour as the previous code would have thrown NPE.
>
> No. This method is called from 3 places,  and there 3 null checks before the method call.

Thanks for double checking! LGTM then.

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

PR: https://git.openjdk.java.net/jdk/pull/7061

From luhenry at openjdk.java.net  Tue May 10 11:51:37 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Tue, 10 May 2022 11:51:37 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1
 polynomial hash loops [v10]
In-Reply-To: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
Message-ID: <HLUvpM8q0UZGCfEMy5DzacjRCZ2sPxdxih4oKMMzPtE=.80fc5a21-daf4-4d17-8ffd-f1f2415ca088@github.com>

> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
> 
> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
> 
> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
> 
> 
> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
> 
> 
> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
> 
> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf

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

  Add missing check for AryHashCode node

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7700/files
  - new: https://git.openjdk.java.net/jdk/pull/7700/files/a6f75c2a..2b631dd2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=08-09

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

PR: https://git.openjdk.java.net/jdk/pull/7700

From shade at openjdk.java.net  Tue May 10 12:10:28 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 12:10:28 GMT
Subject: RFR: 8286473: Drop --enable-preview from Record related tests
Message-ID: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>

There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. 

Additional testing:
 - [x] Linux x86_64 fastdebug, affected tests still pass
 - [x]  Linux x86_32 fastdebug, affected tests start to pass

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/8626

From luhenry at openjdk.java.net  Tue May 10 12:11:26 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Tue, 10 May 2022 12:11:26 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v11]
In-Reply-To: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
Message-ID: <W9IbHNRaJWtCv00KvUHLEK8vKcjDd39UP1yp9DdWlN0=.5d9365ed-30e4-425c-ace5-e7e577faeba7@github.com>

> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
> 
> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
> 
> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
> 
> 
> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
> 
> 
> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
> 
> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf

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

  Fix h when vectorized for Arrays.hashCode

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7700/files
  - new: https://git.openjdk.java.net/jdk/pull/7700/files/2b631dd2..af7b4450

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=09-10

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7700.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7700/head:pull/7700

PR: https://git.openjdk.java.net/jdk/pull/7700

From shade at openjdk.java.net  Tue May 10 12:14:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 12:14:32 GMT
Subject: RFR: 8286474: Drop --enable-preview from Sealed Classes related tests
Message-ID: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>

There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the Sealed Classes tests, since Sealed Classes have been graduated from preview in JDK 17.

Additional testing:
 - [x] Linux x86_64 fastdebug, affected tests still pass
 - [x] Linux x86_32 fastdebug, affected tests start to pass

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

Commit messages:
 - Some

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From duke at openjdk.java.net  Tue May 10 12:29:47 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Tue, 10 May 2022 12:29:47 GMT
Subject: Integrated: 8238373: Punctuation should be same in jlink help usage on
 Japanese language
In-Reply-To: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
References: <6pLW8IQAIimnHy0tq5aNasxMGpulvfS3dKjOCx5KEZc=.098a646b-2b05-47a2-a76b-ce77b129f576@github.com>
Message-ID: <2Y2UyuMLcj63oY8Vk4zTHmin7KWA1enWyKBU-vB0H7U=.68f55b63-ffb4-46c5-88e4-6f5a23b65d71@github.com>

On Wed, 27 Apr 2022 08:59:20 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> When showing help for the jlink command in a Japanese locale, delimiters of option's aliases are a mixture of "," and \u3001. Delimiter should be unified to ",".
> As the same, there is a inconsistency of delimiters in the jar command help in a Japanese locale, and "," should be used.
> Similarly, the javap command help uses space as delimiters other than the module option in all locales. This inconsistency should also be corrected.
> 
> Would you please review this fix?

This pull request has now been integrated.

Changeset: c4bd4499
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c4bd4499f1476dd300d967c556750cf8a5f1c5c7
Stats:     24 lines in 6 files changed: 0 ins; 0 del; 24 mod

8238373: Punctuation should be same in jlink help usage on Japanese language

Reviewed-by: naoto

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

PR: https://git.openjdk.java.net/jdk/pull/8417

From jpai at openjdk.java.net  Tue May 10 12:29:44 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 12:29:44 GMT
Subject: RFR: 8286473: Drop --enable-preview from Record related tests
In-Reply-To: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
References: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
Message-ID: <PA7im3RAJetXF3gyyt2v932wnG906ZlYBds98C3Opfw=.0423da17-2009-4fad-8808-35079dba2568@github.com>

On Tue, 10 May 2022 12:03:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, affected tests still pass
>  - [x]  Linux x86_32 fastdebug, affected tests start to pass

Hello Aleksey, the `unreflect` test package has just one test and that one uses the `record` feature. So removing the `TEST.properties` for that entire package looks fine.

The changes to the other 2 tests look fine too, since like you note, they are just `record` related tests and don't have any other preview feature being tested. I think these two tests would need a copyright year update.

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

PR: https://git.openjdk.java.net/jdk/pull/8626

From sgehwolf at openjdk.java.net  Tue May 10 12:40:42 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 10 May 2022 12:40:42 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
Message-ID: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>

Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).

In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.

Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).

Testing:
- [x] Added unit tests
- [x] GHA
- [x] Container tests on cgroups v1 Linux. Continue to pass

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

Commit messages:
 - 8286212: Cgroup v1 initialization causes NPE on some systems

Changes: https://git.openjdk.java.net/jdk/pull/8629/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286212
  Stats: 267 lines in 7 files changed: 256 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8629.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8629/head:pull/8629

PR: https://git.openjdk.java.net/jdk/pull/8629

From jpai at openjdk.java.net  Tue May 10 12:46:48 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 12:46:48 GMT
Subject: RFR: 8286474: Drop --enable-preview from Sealed Classes related
 tests
In-Reply-To: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
References: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
Message-ID: <yn0WYwi38LXTbrSrxCkedIGQ75n1XXmugaYfWtYlH-0=.3fcc5242-008e-4672-a07b-91744531de92@github.com>

On Tue, 10 May 2022 12:07:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the Sealed Classes tests, since Sealed Classes have been graduated from preview in JDK 17.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, affected tests still pass
>  - [x] Linux x86_32 fastdebug, affected tests start to pass

The changes look fine to me. Both these files will need a copyright year update, I think.

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From jbhateja at openjdk.java.net  Tue May 10 12:48:25 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 10 May 2022 12:48:25 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v3]
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Correcting a typo.
 - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: AARCH64 backend changes.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...b021e082

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

Changes: https://git.openjdk.java.net/jdk/pull/8425/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=02
  Stats: 37901 lines in 214 files changed: 16527 ins; 16924 del; 4450 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425

PR: https://git.openjdk.java.net/jdk/pull/8425

From rafael.wth at gmail.com  Tue May 10 12:49:35 2022
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Tue, 10 May 2022 14:49:35 +0200
Subject: HttpClient has no explicit way of releasing threads
In-Reply-To: <8a5f39ba-064f-2aa8-4744-818c7d3ee7cf@oracle.com>
References: <CA+DM0AmX9edJxK4Hv5NCsaFh7k4TouQhgmfTsCJg2_NquLCzWw@mail.gmail.com>
 <8a5f39ba-064f-2aa8-4744-818c7d3ee7cf@oracle.com>
Message-ID: <CA+DM0AkMVJ44VuC3oDySgV2CtsbiPF3DOK3br24ymffaJeYkYA@mail.gmail.com>

Thanks,

I created a shared client for now which solves my issue. I only stumbled
upon this as a build server increased its use of resources and the change
was that somebody had removed a third-party (closeable) HTTP client to
replace it with the JDK client. Unit tests often aim to be decoupled,
therefore I assume this is an easy mistake to make. To be fair, while it
might be inefficient to recreate the client for each test class, the value
of a decoupled test suite might be higher, so I understand why the
developer went for this solution.

I'd appreciate a method for explicit disposal and possibly a clarification
in the javadoc of HttpClient how resources are held. I had to dig through
the sources of the client to understand what happened.

Thanks, Rafael

Daniel Fuchs <daniel.fuchs at oracle.com> schrieb am Di., 10. Mai 2022, 13:37:

> Hi Rafael,
>
> On 09/05/2022 22:43, Rafael Winterhalter wrote:
> > Hello,
> >
> > looking at thread dumps, I realized that the HttpClient implementation
> does
> > not offer an explicit way to release its threads. Currently, the client:
> >
> > 1. maintains a cached thread pool with a retention size of 60 seconds. If
> > many such clients are created for short lived application, these threads
> > pile up.
> > 2. has a selector thread that only shuts down if the outer "facade"
> > reference is collected via a weak reference. If an application is not
> > running GC, this can take a while.
> >
> > This is not a big problem but I have seen peaks with suddenly many, many
> > threads (in test code) where many HttpClients were created for single use
> > and I was wondering if it was ever considered to add a method for
> disposing
> > the threads explicitly?
>
> I would consider it bad practice to create an HttpClient instance for
> single usage; Ideally a client should be reused - provided that
> the security context is the same. Creating an HttpClient involves
> creating a thread pool, a selector, a selector manager thread,
> potentially initializing an SSL context etc...
>
> WRT to adding a method for disposing the HttpClient explicitly, then
> yes - that's something that we could consider for a major
> release. It would need to be carefully specified - especially WRT what
> would be the effect of calling this method if some operations are still
> in progress. Asynchronously closing objects that are still in use is
> a notoriously thorny subject.
> We might need something equivalent to what is defined for executor
> services - that is - one variant that waits for all ongoing operations
> to terminate before closing, and one that abruptly aborts any
> on-going operation.
>
> > Alternatively, it might be an option to add a method like
> > HttpClient.shared() which would return a singleton HttpClient (created on
> > the first call, collected if no reference is kept anymore but reused in
> the
> > meantime) to address such scenarios. I can of course add a singleton in
> my
> > test project but I find this a bit awkward as it is something to remember
> > and to repeat in all applications we maintain. Therefore, it might be
> > convenient to add such methods for tests that usually aim to be
> decoupled.
>
> An HttpClient is a kind of capability object so I don't think we want
> to have a shared client in the Java API. That's something that
> an application can easily implement at the application level if it
> makes sense for the application.
>
> A possibility to work around the thread peak issue is also for an
> application to configure its own thread executor on the HttpClient.
> If that makes sense for the application and if it is safe to do
> so the executor can also be shared between several client.
> It is then the responsibility of the application
> to shutdown the executor when the clients are no longer in use.
>
> >
> > Thanks for your consideration,
> > best regards, Rafael
>
> best regards,
>
> -- daniel
>

From alanb at openjdk.java.net  Tue May 10 12:51:07 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 12:51:07 GMT
Subject: RFR: 8286474: Drop --enable-preview from Sealed Classes related
 tests
In-Reply-To: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
References: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
Message-ID: <P2jbw1JLbtcwEBjtDCvDtaeSuBUdqLYgqBi9lPjGmBU=.01b2cd5a-7abb-42d1-9bed-00cbd7a2e690@github.com>

On Tue, 10 May 2022 12:07:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the Sealed Classes tests, since Sealed Classes have been graduated from preview in JDK 17.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, affected tests still pass
>  - [x] Linux x86_32 fastdebug, affected tests start to pass

test/jdk/java/lang/reflect/sealed_classes/SealedClassesReflectionTest.java line 29:

> 27:  * @summary reflection test for sealed classes
> 28:  * @compile -source ${jdk.version} SealedClassesReflectionTest.java
> 29:  * @run testng/othervm SealedClassesReflectionTest

You should be able to drop` -source ${jdk.version}` too. It was required when compiling with `--enable-preview`.

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From duke at openjdk.java.net  Tue May 10 13:19:50 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 10 May 2022 13:19:50 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v2]
In-Reply-To: <2dY3mGc0yxKMCvVTzM-HRNJkS0EBQopGwYeOJ955Zs8=.1de84afe-d76f-4c86-b0f0-c7a1b6dcca0c@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <6wOeHEcFHPv0-dg-v19u3S1SNUXTa7FcUJGdrrEFoOs=.21bc13d5-dba5-4011-9f16-aae52707d4c0@github.com>
 <2dY3mGc0yxKMCvVTzM-HRNJkS0EBQopGwYeOJ955Zs8=.1de84afe-d76f-4c86-b0f0-c7a1b6dcca0c@github.com>
Message-ID: <ajjHJ6mbfiTBMWRw4lyoWt4LbHkkVgaFf48DfPqudnU=.a41b8830-e7a0-435f-a7f8-1ad1625e059f@github.com>

On Tue, 10 May 2022 04:42:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti 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:
>> 
>>  - 8279986: methods Math::asXExact for safely checked primitive casts
>>    
>>    Merge branch 'master' into JDK-8279986
>>  - 8279986: methods Math::asXExact for safely checked primitive casts
>>    
>>    Merge branch 'master' into JDK-8279986
>>  - 8279986: methods Math::asXExact for safely checked primitive casts
>>  - 8279986: methods Math::asXExact for safely checked primitive casts
>
> src/java.base/share/classes/java/lang/Math.java line 1578:
> 
>> 1576:      */
>> 1577:     @ForceInline
>> 1578:     public static long toUnsignedIntExact(long value) {
> 
> Existing methods like Integer.parseUnsignedInt interpret the negative int values as positive values larger than MAX_INT. So if an int is not going to be returned here, I suggest a name like "toUnsignedIntRangeExact".

Returning a `long` is probably less error prone.

When the result is to be used in an `int` context, one simply has to add a `(int)` cast, as mandated by language, compiler and IDE.

On the other hand, if this method were to return an `int`, when using the result in a `long` context one has to remember masking it with `0xFFFF_FFFFL`. AFAIK, there's no compiler or IDE support for this.

The name `toUnsignedIntRangeExact` is certainly better.

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

PR: https://git.openjdk.java.net/jdk/pull/8548

From jpai at openjdk.java.net  Tue May 10 13:15:47 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 13:15:47 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected
In-Reply-To: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
Message-ID: <s-QyGkoKSvHjirrxqsW1AFBXqmxX_MZw-qZmU8rMi-M=.58872449-58e1-4fc4-9d1a-a5e953ec9b84@github.com>

On Mon, 9 May 2022 18:59:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

src/java.base/share/classes/java/util/TimeZone.java line 109:

> 107:  * <blockquote><pre>
> 108:  * <a id="NormalizedCustomID"><i>NormalizedCustomID:</i></a>
> 109:  *         {@code GMT} <i>Sign</i> <i>TwoDigitHours</i> {@code :} <i>Minutes</i> [<i>Seconds</i>]

Hello Naoto,

Should this instead be: `... <i>Minutes</i> [{@code :} <i>Seconds</i>]` - i.e. should it have the `:` literal if seconds are present in the custom timezone id?

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

PR: https://git.openjdk.java.net/jdk/pull/8606

From forax at univ-mlv.fr  Tue May 10 13:39:04 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 10 May 2022 15:39:04 +0200 (CEST)
Subject: HttpClient has no explicit way of releasing threads
In-Reply-To: <CA+DM0AmX9edJxK4Hv5NCsaFh7k4TouQhgmfTsCJg2_NquLCzWw@mail.gmail.com>
References: <CA+DM0AmX9edJxK4Hv5NCsaFh7k4TouQhgmfTsCJg2_NquLCzWw@mail.gmail.com>
Message-ID: <1923982658.23683953.1652189944082.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Rafael Winterhalter" <rafael.wth at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Monday, May 9, 2022 11:43:49 PM
> Subject: HttpClient has no explicit way of releasing threads

> Hello,

Hello,

> 
> looking at thread dumps, I realized that the HttpClient implementation does
> not offer an explicit way to release its threads. Currently, the client:
> 
> 1. maintains a cached thread pool with a retention size of 60 seconds. If
> many such clients are created for short lived application, these threads
> pile up.
> 2. has a selector thread that only shuts down if the outer "facade"
> reference is collected via a weak reference. If an application is not
> running GC, this can take a while.
> 
> This is not a big problem but I have seen peaks with suddenly many, many
> threads (in test code) where many HttpClients were created for single use
> and I was wondering if it was ever considered to add a method for disposing
> the threads explicitly?

You can change the Executor (it's one parameter of the builder) to use whatever executors you want so you can shutdown that executor as you want.
This should fixed (1).

Also once you update to Java 19/21, it seems a good scenario to test the executor that spawn virtual threads instead of platform threads.

> 
> Alternatively, it might be an option to add a method like
> HttpClient.shared() which would return a singleton HttpClient (created on
> the first call, collected if no reference is kept anymore but reused in the
> meantime) to address such scenarios. I can of course add a singleton in my
> test project but I find this a bit awkward as it is something to remember
> and to repeat in all applications we maintain. Therefore, it might be
> convenient to add such methods for tests that usually aim to be decoupled.
> 
> Thanks for your consideration,
> best regards, Rafael

regards,
R?mi

From duke at openjdk.java.net  Tue May 10 13:47:35 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 10 May 2022 13:47:35 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v3]
In-Reply-To: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
Message-ID: <8wSTD-EmbxMEVwd9hPfLPCudwb-Rrj-tTt80F9o1Npc=.8146bcf1-31ce-4322-afd1-f26591ff48f4@github.com>

> Add a family of "safe" cast methods.

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

  8279986: methods Math::asXExact for safely checked primitive casts

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8548/files
  - new: https://git.openjdk.java.net/jdk/pull/8548/files/7be0f9de..5f0ff527

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

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

PR: https://git.openjdk.java.net/jdk/pull/8548

From daniel.fuchs at oracle.com  Tue May 10 13:53:28 2022
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 10 May 2022 14:53:28 +0100
Subject: HttpClient has no explicit way of releasing threads
In-Reply-To: <1923982658.23683953.1652189944082.JavaMail.zimbra@u-pem.fr>
References: <CA+DM0AmX9edJxK4Hv5NCsaFh7k4TouQhgmfTsCJg2_NquLCzWw@mail.gmail.com>
 <1923982658.23683953.1652189944082.JavaMail.zimbra@u-pem.fr>
Message-ID: <29c81c31-3a99-3731-b63d-83c76c407c36@oracle.com>

On 10/05/2022 14:39, Remi Forax wrote:
>> This is not a big problem but I have seen peaks with suddenly many, many
>> threads (in test code) where many HttpClients were created for single use
>> and I was wondering if it was ever considered to add a method for disposing
>> the threads explicitly?
> You can change the Executor (it's one parameter of the builder) to use whatever executors you want so you can shutdown that executor as you want.
> This should fixed (1).
> 
> Also once you update to Java 19/21, it seems a good scenario to test the executor that spawn virtual threads instead of platform threads.
> 

Some word of caution about shutting down the executor:
If you know that the client is no longer used, and there are
no requests in progress, what R?mi suggests should be fine.
Otherwise shutting down the executor when the client is still
in use could lead to undefined behaviour, including not
being able to complete the CompletableFutures that have
been returned by `sendAsync` - or which `send` calls have
joined.

This has been fixed in JDK 19 by JDK-8277969, but otherwise,
and especially on previous versions of the JDK, you should
make sure that all operations have terminated before shutting
down the executor (even gracefully).

Using virtual threads should be fine - as long as they are not
pooled :-)

best regards,

-- daniel

From mdoerr at openjdk.java.net  Tue May 10 13:55:55 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 10 May 2022 13:55:55 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
Message-ID: <ffsUxlpoYXt7ABsFh4zbUlzjqZAHWTnrctHVwKgZw_Y=.461b26a5-5237-498e-a99f-128869a10290@github.com>

On Mon, 9 May 2022 22:10:54 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> After https://bugs.openjdk.java.net/browse/JDK-8251329, javac throws errors when the classpath
> contains jar files with . or .. in its name. The error message, however, does not help to find
> the culprit. This could be improved.

LGTM. I think this is an important improvement. Developers should not be left alone figuring out which .jar file is responsible for the problem. There is currently no hint at all without this change.
(Note: Pre-submit test issues on 32 bit are unrelated.)

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8616

From alanb at openjdk.java.net  Tue May 10 14:05:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 14:05:49 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
Message-ID: <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>

On Mon, 9 May 2022 22:32:57 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?

It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for that in the String representation).

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From jpai at openjdk.java.net  Tue May 10 14:24:00 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 14:24:00 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected
In-Reply-To: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
Message-ID: <lNBKz0aaVzte_LjPBWf6vtDy4C0_U7BKXrsjTlwuEdM=.8848cec9-5417-4ab7-b46a-1950e9a2926d@github.com>

On Mon, 9 May 2022 18:59:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

src/java.base/share/classes/java/util/TimeZone.java line 543:

> 541:             return new ZoneInfo(totalSecs == 0 ? "UTC" : GMT_ID + tzid, totalSecs);
> 542:         } else {
> 543:             return getTimeZone(tzid, true);

Before the change in this PR, we used to prefix `GMT` to (non-custom timezone ids) if the timezone id returned by `ZoneId#getId()` started with the `+` or `-` sign, before calling `getTimeZone(modifiedTzid, true)`. 
With this change, for `ZoneId`s that aren't `ZoneOffset` instance, we now call `getTimeZone(originalTzid, true)`, without first checking/prefixing the id with `GMT`. Is that an intentional change and would that potentially cause `getTimeZone(String, boolean)` to return a different result?

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

PR: https://git.openjdk.java.net/jdk/pull/8606

From duke at openjdk.java.net  Tue May 10 14:30:30 2022
From: duke at openjdk.java.net (Chris Hennick)
Date: Tue, 10 May 2022 14:30:30 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential
Message-ID: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>

Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around 2*exponentialX0 == 0x1.e46eff20739afp3); this fixes that by tracking the multiple of exponentialX0 as a long. (This changes the maximum possible output to `1.0p63 * DoubleZigguratTables.exponentialX0 == 0x1.e46eff20739afp65`; previously it would have been `0x1.0p56` because once `extra` reaches that amount, `x + extra == extra` due to the rounding error. This lowers the probability of reaching the maximum with an ideal PRNG from about `1.3877787807814488E-17` to about `1.4323726067488646E-20` (calculated using the identity `ln(x) == Math.log10(x)/Math.log10(Math.exp(1))`).

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

Commit messages:
 - Fix rounding error in computeNextExponential; use FMA

Changes: https://git.openjdk.java.net/jdk/pull/8131/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8131&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284493
  Stats: 43 lines in 1 file changed: 33 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8131/head:pull/8131

PR: https://git.openjdk.java.net/jdk/pull/8131

From xliu at openjdk.java.net  Tue May 10 14:30:30 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 10 May 2022 14:30:30 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <B1pJbSGCdyoLVkZmtO43fKtGKnfEbVk-21kZSK2Rdwk=.6b3ba914-3b1d-4650-9301-0d5b73802af3@github.com>

On Wed, 6 Apr 2022 17:47:53 GMT, Chris Hennick <duke at openjdk.java.net> wrote:

> Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around 2*exponentialX0 == 0x1.e46eff20739afp3); this fixes that by tracking the multiple of exponentialX0 as a long. (This changes the maximum possible output to `1.0p63 * DoubleZigguratTables.exponentialX0 == 0x1.e46eff20739afp65`; previously it would have been `0x1.0p56` because once `extra` reaches that amount, `x + extra == extra` due to the rounding error. This lowers the probability of reaching the maximum with an ideal PRNG from about `1.3877787807814488E-17` to about `1.4323726067488646E-20` (calculated using the identity `ln(x) == Math.log10(x)/Math.log10(Math.exp(1))`).

hi, @JesperIRL, 
Could you help us on OCA coverage?

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

PR: https://git.openjdk.java.net/jdk/pull/8131

From duke at openjdk.java.net  Tue May 10 14:30:31 2022
From: duke at openjdk.java.net (Chris Hennick)
Date: Tue, 10 May 2022 14:30:31 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <--5kxBaSLG_ssb0IJHjgOnUSwGzce3LRAQmU7Fgou0Q=.7ae921d5-51fa-4b88-82e1-ced46c618b85@github.com>

On Wed, 6 Apr 2022 17:47:53 GMT, Chris Hennick <duke at openjdk.java.net> wrote:

> Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around 2*exponentialX0 == 0x1.e46eff20739afp3); this fixes that by tracking the multiple of exponentialX0 as a long. (This changes the maximum possible output to `1.0p63 * DoubleZigguratTables.exponentialX0 == 0x1.e46eff20739afp65`; previously it would have been `0x1.0p56` because once `extra` reaches that amount, `x + extra == extra` due to the rounding error. This lowers the probability of reaching the maximum with an ideal PRNG from about `1.3877787807814488E-17` to about `1.4323726067488646E-20` (calculated using the identity `ln(x) == Math.log10(x)/Math.log10(Math.exp(1))`).

Should we extract a computeWinsorizedNextExponential that can compute a smaller value for line 1216 to compare the output to, so that line 1218 can realistically be covered in a unit test? Such a method might even be worth exposing in the RandomGenerator interface, in case an approximately exponential distribution is ever needed in a hard real-time system.

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

PR: https://git.openjdk.java.net/jdk/pull/8131

From jpai at openjdk.java.net  Tue May 10 14:35:54 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 14:35:54 GMT
Subject: RFR: 8285285: Avoid redundant allocations in WindowsPreferences
In-Reply-To: <8-W0hk5YK-0sIJewKJLikzklE6V--uui3wCgQLS4suI=.0194a658-1b8d-4deb-b177-0d402d590b5b@github.com>
References: <8-W0hk5YK-0sIJewKJLikzklE6V--uui3wCgQLS4suI=.0194a658-1b8d-4deb-b177-0d402d590b5b@github.com>
Message-ID: <xkpkj1mPPZU-b2QNX7_thbLgCMGGV7wohqSJUvq5FFg=.35e9dfdc-42b2-4fd0-acac-b0afa40b4da6@github.com>

On Wed, 20 Apr 2022 19:16:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 1. No need to call `String.substring` if you need need to compare start of string with some constant. `String.startWith` suites better.
> 2. Unused String array is allocated in `childrenNamesSpi` method

Marked as reviewed by jpai (Committer).

I don't have knowledge of this area, but these changes look good to me.

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

PR: https://git.openjdk.java.net/jdk/pull/8322

From alanb at openjdk.java.net  Tue May 10 14:46:50 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 14:46:50 GMT
Subject: RFR: 8286473: Drop --enable-preview from Record related tests
In-Reply-To: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
References: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
Message-ID: <WuE9OoQGRI8jLHLsZgRHqxi4hrXttuTvfcFnF9IRIs4=.049aa32c-bb30-4efd-b8d5-ed729ea028ee@github.com>

On Tue, 10 May 2022 12:03:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, affected tests still pass
>  - [x]  Linux x86_32 fastdebug, affected tests start to pass

test/jdk/java/nio/Buffer/BulkPutBuffer.java line 57:

> 55:  * @run testng/othervm BulkPutBuffer
> 56:  */
> 57: public class BulkPutBuffer {

You can drop the -source option from these tests too.

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

PR: https://git.openjdk.java.net/jdk/pull/8626

From luhenry at openjdk.java.net  Tue May 10 14:46:56 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Tue, 10 May 2022 14:46:56 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v12]
In-Reply-To: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
Message-ID: <PP7oByBGJce2DZZTe_1W4dtmld2cYUyBj-MiJEo0E58=.904b7b82-0333-4520-918b-0314f0e8fa3a@github.com>

> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
> 
> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
> 
> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
> 
> 
> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
> 
> 
> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
> 
> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf

Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Fix overlapping registers
 - Actually fix h when hashcode is vectorized
 - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
 - Fix h when vectorized for Arrays.hashCode
 - Add missing check for AryHashCode node
 - Fix some merge conflicts
 - Disable Arrays.hashCode intrinsic by default for CI
 - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
 - Some small refactoring: store power_of_31_backwards in the code directly, compact code, and more
 - {wip} Generalize string hashcode to Arrays.hashCode
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...29dab16b

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

Changes: https://git.openjdk.java.net/jdk/pull/7700/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=11
  Stats: 1151 lines in 25 files changed: 1140 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7700.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7700/head:pull/7700

PR: https://git.openjdk.java.net/jdk/pull/7700

From luhenry at openjdk.java.net  Tue May 10 14:46:57 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Tue, 10 May 2022 14:46:57 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v2]
In-Reply-To: <09Y4yqHXagErs9xsjNeoajWf_BNFhQa4FYAcScfbj0U=.a1307e83-564a-4a76-a65c-d4e29234e90a@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
 <rzQygFy7dmvWvHCL9tMCXwnAdja064d8vPQ_-9sa9V4=.08dbb292-0713-4bc7-988e-bd20f22d1087@github.com>
 <CS97YgmTA_k8anK0N3Ag45bnAyQIErlNF4KxgPGEhQY=.1f489796-ceb4-4bec-bc33-e987921d2425@github.com>
 <LaOfMZRAGRYDoE41RSMhZxtJhzgnUJ4QZgtoT3oijBQ=.5dd1becd-3dd7-4fa2-b253-907d585a70d7@github.com>
 <09Y4yqHXagErs9xsjNeoajWf_BNFhQa4FYAcScfbj0U=.a1307e83-564a-4a76-a65c-d4e29234e90a@github.com>
Message-ID: <Bc5gIB2e9YUQT9FykKXNB7TDXQQ8NfV9aCzbsAfm-I4=.537f0d3d-1c19-4e2f-93a3-13acfb51d000@github.com>

On Tue, 8 Mar 2022 17:07:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>>> Can we change the optimizer so that the strength reduction happens only after all transformations have settled? Carelessly changing a multiplication to a shift as today may hurt a lot of potential optimisations. Thanks.
>> 
>> Yes, it's troubling that making a constant non-foldable can lead the JIT down a path that ultimately pessimizes the end result (as observed here). If we could train the JIT to avoid this pitfall and get to the improvement observed in my experiment here without any changes to `String.java` then that'd be great.
>
>> @cl4es Yes, we would need to carefully measure the impact for small array sizes (similar to what we had to do when the array mismatch intrinsic was implemented and applied to array equals). My sense is to focus on the intrinsic and also look for potential opportunities like @merykitty points out, as that is where the larger impact is, although it is more work!
> 
> Right, I'm not too thrilled about the prospect of moving ahead with the de-constantification as an alternative patch here. It's such a crutch, but it's also simple and has no obvious downsides as of right now. I think it was a useful experiment to see where some of the gain observed in the unroll might be coming from. The degradation on many smaller `Strings` in the unrolled versions is a concern that I think might be a blocker, though. Short Strings are excessively common as keys in hash maps et.c.. 
> 
> Feels like none of the alternatives seen here so far is really _it_.

@cl4es that was indeed the issue leading to the crash. Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/7700

From shade at openjdk.java.net  Tue May 10 14:54:39 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 14:54:39 GMT
Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2]
In-Reply-To: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
References: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
Message-ID: <N50hBys42VgQvYc5wQbCUqhHC0gQxGZREXWGrx6I7fk=.f9b83ace-b449-4dda-b2b1-db0cfaf43c08@github.com>

> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, affected tests still pass
>  - [x]  Linux x86_32 fastdebug, affected tests start to pass

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

  Review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8626/files
  - new: https://git.openjdk.java.net/jdk/pull/8626/files/d5f0b1be..626e673a

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

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

PR: https://git.openjdk.java.net/jdk/pull/8626

From alanb at openjdk.java.net  Tue May 10 14:54:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 14:54:40 GMT
Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2]
In-Reply-To: <N50hBys42VgQvYc5wQbCUqhHC0gQxGZREXWGrx6I7fk=.f9b83ace-b449-4dda-b2b1-db0cfaf43c08@github.com>
References: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
 <N50hBys42VgQvYc5wQbCUqhHC0gQxGZREXWGrx6I7fk=.f9b83ace-b449-4dda-b2b1-db0cfaf43c08@github.com>
Message-ID: <P_Fb_w5KvjVWPh2WNYjx7KsdDuJDqTPMt4W3OG72WZA=.c76bdc23-8a3a-4812-82d2-8120e8636102@github.com>

On Tue, 10 May 2022 14:51:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x]  Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8626

From shade at openjdk.java.net  Tue May 10 14:54:40 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 14:54:40 GMT
Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2]
In-Reply-To: <WuE9OoQGRI8jLHLsZgRHqxi4hrXttuTvfcFnF9IRIs4=.049aa32c-bb30-4efd-b8d5-ed729ea028ee@github.com>
References: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
 <WuE9OoQGRI8jLHLsZgRHqxi4hrXttuTvfcFnF9IRIs4=.049aa32c-bb30-4efd-b8d5-ed729ea028ee@github.com>
Message-ID: <dXGUiaJuzyaMoSJNBKYo0Y_P7E33nhBgJBtzb_k04NY=.79e9baf6-49e3-43af-8271-3a1ba54d59b7@github.com>

On Tue, 10 May 2022 14:43:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/java/nio/Buffer/BulkPutBuffer.java line 57:
> 
>> 55:  * @run testng/othervm BulkPutBuffer
>> 56:  */
>> 57: public class BulkPutBuffer {
> 
> You can drop the -source option from these tests too.

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/8626

From shade at openjdk.java.net  Tue May 10 14:58:15 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 14:58:15 GMT
Subject: RFR: 8286474: Drop --enable-preview from Sealed Classes related
 tests [v2]
In-Reply-To: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
References: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
Message-ID: <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>

> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the Sealed Classes tests, since Sealed Classes have been graduated from preview in JDK 17.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, affected tests still pass
>  - [x] Linux x86_32 fastdebug, affected tests start to pass

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

  Review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8627/files
  - new: https://git.openjdk.java.net/jdk/pull/8627/files/9b1a55a3..1b74acf4

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

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From alanb at openjdk.java.net  Tue May 10 14:58:16 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 14:58:16 GMT
Subject: RFR: 8286474: Drop --enable-preview from Sealed Classes related
 tests [v2]
In-Reply-To: <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>
References: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
 <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>
Message-ID: <llaxlGDcAeqD_vOUVZ0EvCMejtYUmWpsxJG7dquh1JU=.48ef3771-b4d7-4dd3-afbc-460f2cdac8cd@github.com>

On Tue, 10 May 2022 14:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the Sealed Classes tests, since Sealed Classes have been graduated from preview in JDK 17.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x] Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From shade at openjdk.java.net  Tue May 10 14:58:18 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 May 2022 14:58:18 GMT
Subject: RFR: 8286474: Drop --enable-preview from Sealed Classes related
 tests [v2]
In-Reply-To: <P2jbw1JLbtcwEBjtDCvDtaeSuBUdqLYgqBi9lPjGmBU=.01b2cd5a-7abb-42d1-9bed-00cbd7a2e690@github.com>
References: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
 <P2jbw1JLbtcwEBjtDCvDtaeSuBUdqLYgqBi9lPjGmBU=.01b2cd5a-7abb-42d1-9bed-00cbd7a2e690@github.com>
Message-ID: <0w5QUwyN59LIdTar7n3mP8hbWxqoyH8Gp0OE38Z75WI=.aa7871e4-f44b-4f98-826d-ac8aea9a0a55@github.com>

On Tue, 10 May 2022 12:47:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/java/lang/reflect/sealed_classes/SealedClassesReflectionTest.java line 29:
> 
>> 27:  * @summary reflection test for sealed classes
>> 28:  * @compile -source ${jdk.version} SealedClassesReflectionTest.java
>> 29:  * @run testng/othervm SealedClassesReflectionTest
> 
> You should be able to drop` -source ${jdk.version}` too. It was required when compiling with `--enable-preview`.

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From jpai at openjdk.java.net  Tue May 10 15:00:04 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 15:00:04 GMT
Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2]
In-Reply-To: <N50hBys42VgQvYc5wQbCUqhHC0gQxGZREXWGrx6I7fk=.f9b83ace-b449-4dda-b2b1-db0cfaf43c08@github.com>
References: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
 <N50hBys42VgQvYc5wQbCUqhHC0gQxGZREXWGrx6I7fk=.f9b83ace-b449-4dda-b2b1-db0cfaf43c08@github.com>
Message-ID: <TbPiiucPLb87V3y86nOus9Oabz4pWNGC6-MSyD_NiWU=.2976cbd4-9ada-4381-ac9d-b18eee5aa059@github.com>

On Tue, 10 May 2022 14:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x]  Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by jpai (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/8626

From jpai at openjdk.java.net  Tue May 10 15:15:48 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 15:15:48 GMT
Subject: RFR: 8286474: Drop --enable-preview from Sealed Classes related
 tests [v2]
In-Reply-To: <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>
References: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
 <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>
Message-ID: <dMcS8fKlPgAo74NmpIYjg8dOlSDCY3r5o76ZL4QvQMI=.17a9d82c-d650-4be7-b612-ea8b1ee7795d@github.com>

On Tue, 10 May 2022 14:58:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the Sealed Classes tests, since Sealed Classes have been graduated from preview in JDK 17.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x] Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by jpai (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From bpb at openjdk.java.net  Tue May 10 15:34:52 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 10 May 2022 15:34:52 GMT
Subject: Integrated: 8286363: BigInteger.parallelMultiply missing @since 19
In-Reply-To: <JssBLeop7k2Zb0XpGI0wT4okV5kJxq1ySkmwJusQAyU=.4923d068-9cf6-4d5e-a1fe-c749e6ab8944@github.com>
References: <JssBLeop7k2Zb0XpGI0wT4okV5kJxq1ySkmwJusQAyU=.4923d068-9cf6-4d5e-a1fe-c749e6ab8944@github.com>
Message-ID: <yg1RbT4mbrBYF9rAUBHBnBdDXfdFtwkc97tiNvvEOMw=.4098e031-961a-4204-980f-faa8a030eafc@github.com>

On Mon, 9 May 2022 15:26:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add missing `@since 19` tag.

This pull request has now been integrated.

Changeset: 04bba07d
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/04bba07d6588cb96e371f3acdb49d735c9e6536d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8286363: BigInteger.parallelMultiply missing @since 19

Reviewed-by: alanb, darcy

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

PR: https://git.openjdk.java.net/jdk/pull/8598

From duke at openjdk.java.net  Tue May 10 15:53:49 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 10 May 2022 15:53:49 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v11]
In-Reply-To: <UkougCywkC6YSJeQRa0G5TCY6H8xZheWyGpZwLUCyqM=.6b53d8f9-b0f8-470b-bfec-368056d706bf@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>
 <UkougCywkC6YSJeQRa0G5TCY6H8xZheWyGpZwLUCyqM=.6b53d8f9-b0f8-470b-bfec-368056d706bf@github.com>
Message-ID: <j0El14oLsZ55beIEuFr54t-0_JjGGwWzikd0_NDxrh0=.9c764adf-5e3b-4e51-a74c-d67485589722@github.com>

On Tue, 10 May 2022 03:21:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   4511638: Double.toString(double) sometimes produces incorrect results
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 882:
> 
>> 880:         try {
>> 881:             FloatToDecimal.appendTo(f, this);
>> 882:         } catch (IOException ignored) {
> 
> What is the motivation for wrapping with IOException?

`[Float|Double]ToDecimal` do not have access to `AbstractStringBuilder`, so have to fail over `Appendable`, which can throw `IOException` in `append(*)` methods.

I have to find another way if this wrapping to make the compiler happy is unacceptable.

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

PR: https://git.openjdk.java.net/jdk/pull/3402

From mchung at openjdk.java.net  Tue May 10 16:24:41 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 10 May 2022 16:24:41 GMT
Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2]
In-Reply-To: <N50hBys42VgQvYc5wQbCUqhHC0gQxGZREXWGrx6I7fk=.f9b83ace-b449-4dda-b2b1-db0cfaf43c08@github.com>
References: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
 <N50hBys42VgQvYc5wQbCUqhHC0gQxGZREXWGrx6I7fk=.f9b83ace-b449-4dda-b2b1-db0cfaf43c08@github.com>
Message-ID: <H2OtF058s2fCg3LF3I1p0u6Tk6HMCzzXOwDU9CqdAZY=.da49c593-3938-474d-aae9-fb9fb1686c31@github.com>

On Tue, 10 May 2022 14:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x]  Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8626

From mchung at openjdk.java.net  Tue May 10 16:24:46 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 10 May 2022 16:24:46 GMT
Subject: RFR: 8286474: Drop --enable-preview from Sealed Classes related
 tests [v2]
In-Reply-To: <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>
References: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
 <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>
Message-ID: <aee5ZKHwfKPgV8m1OKbZ_1jOXlux2_n2UIKGXJb43wA=.f811ea3d-5818-401f-8b43-0ccb318f8478@github.com>

On Tue, 10 May 2022 14:58:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the Sealed Classes tests, since Sealed Classes have been graduated from preview in JDK 17.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x] Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From lancea at openjdk.java.net  Tue May 10 16:32:43 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 10 May 2022 16:32:43 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
Message-ID: <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>

On Tue, 10 May 2022 14:02:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> 
> It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).

I think this would be OK, but would get to get someone from our security team to bless it.  

It might not be a bad idea to add a method to return the name as a String.  There are a couple of places where we do a new String(name) so would economize any future changes

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From lancea at openjdk.java.net  Tue May 10 16:41:45 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 10 May 2022 16:41:45 GMT
Subject: RFR: 8286474: Drop --enable-preview from Sealed Classes related
 tests [v2]
In-Reply-To: <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>
References: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
 <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>
Message-ID: <K6ThOTduNTqzCM2_r2vYUi2j4DGI9APNV1N4X3trZrM=.fc23567f-8de2-4cbb-919f-89d5c0e06662@github.com>

On Tue, 10 May 2022 14:58:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the Sealed Classes tests, since Sealed Classes have been graduated from preview in JDK 17.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x] Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From mchung at openjdk.java.net  Tue May 10 16:43:03 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 10 May 2022 16:43:03 GMT
Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to
 reduce allocation pressure [v2]
In-Reply-To: <mWNCEl3SGAnUluIIw9IZVtzwFcQAuOfJlzylwZ3s2tE=.58bc7b09-ecd3-491a-8a85-9195ba52ae32@github.com>
References: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
 <mWNCEl3SGAnUluIIw9IZVtzwFcQAuOfJlzylwZ3s2tE=.58bc7b09-ecd3-491a-8a85-9195ba52ae32@github.com>
Message-ID: <tedK0IzqTvP8cK_4gjqz5jxUuv705UG0LftsC9JCOsM=.da8267d2-0edd-4349-9aeb-8107f26a2dec@github.com>

On Wed, 4 May 2022 09:46:00 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282701: Revert some irrelevant changes

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/7714

From rafael.wth at gmail.com  Tue May 10 16:47:30 2022
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Tue, 10 May 2022 18:47:30 +0200
Subject: HttpClient has no explicit way of releasing threads
In-Reply-To: <1923982658.23683953.1652189944082.JavaMail.zimbra@u-pem.fr>
References: <CA+DM0AmX9edJxK4Hv5NCsaFh7k4TouQhgmfTsCJg2_NquLCzWw@mail.gmail.com>
 <1923982658.23683953.1652189944082.JavaMail.zimbra@u-pem.fr>
Message-ID: <CA+DM0AkMLUx1KgBjb-81TGv4Cma7TdvYMTNwh9GrKRKjk49e1Q@mail.gmail.com>

The issue would still exist as the selector thread is not spawned from this
executor and also lives until the outer reference is garbage collected. In
my case, this quickly resulted in a few hundred threads from a
parameterized test. Also, I think that its unlikely that a drive-by
instance would be initiated with an explicit instance.

I understand it's not easily solved or avoided. For now, an explicit
warning in the javadoc might be the most sensitive solution.

Remi Forax <forax at univ-mlv.fr> schrieb am Di., 10. Mai 2022, 15:39:

> ----- Original Message -----
> > From: "Rafael Winterhalter" <rafael.wth at gmail.com>
> > To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Sent: Monday, May 9, 2022 11:43:49 PM
> > Subject: HttpClient has no explicit way of releasing threads
>
> > Hello,
>
> Hello,
>
> >
> > looking at thread dumps, I realized that the HttpClient implementation
> does
> > not offer an explicit way to release its threads. Currently, the client:
> >
> > 1. maintains a cached thread pool with a retention size of 60 seconds. If
> > many such clients are created for short lived application, these threads
> > pile up.
> > 2. has a selector thread that only shuts down if the outer "facade"
> > reference is collected via a weak reference. If an application is not
> > running GC, this can take a while.
> >
> > This is not a big problem but I have seen peaks with suddenly many, many
> > threads (in test code) where many HttpClients were created for single use
> > and I was wondering if it was ever considered to add a method for
> disposing
> > the threads explicitly?
>
> You can change the Executor (it's one parameter of the builder) to use
> whatever executors you want so you can shutdown that executor as you want.
> This should fixed (1).
>
> Also once you update to Java 19/21, it seems a good scenario to test the
> executor that spawn virtual threads instead of platform threads.
>
> >
> > Alternatively, it might be an option to add a method like
> > HttpClient.shared() which would return a singleton HttpClient (created on
> > the first call, collected if no reference is kept anymore but reused in
> the
> > meantime) to address such scenarios. I can of course add a singleton in
> my
> > test project but I find this a bit awkward as it is something to remember
> > and to repeat in all applications we maintain. Therefore, it might be
> > convenient to add such methods for tests that usually aim to be
> decoupled.
> >
> > Thanks for your consideration,
> > best regards, Rafael
>
> regards,
> R?mi
>

From clanger at openjdk.java.net  Tue May 10 16:51:37 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 10 May 2022 16:51:37 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
Message-ID: <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>

On Tue, 10 May 2022 16:30:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> > 
> > 
> > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> 
> I think this would be OK, but would get to get someone from our security team to bless it.
> 
> It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes

Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From alanb at openjdk.java.net  Tue May 10 16:54:54 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 16:54:54 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
Message-ID: <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>

On Tue, 10 May 2022 16:48:30 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> I think this would be OK, but would get to get someone from our security team to bless it.

It's print the entry name, I don't think it is leaking the file path to the zip file.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From lancea at openjdk.java.net  Tue May 10 17:02:47 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 10 May 2022 17:02:47 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
Message-ID: <yYSzj3nN7pHVcBewPXh-Sm6Y6x0C4MZ0GRVXJfya9s0=.54612983-b10f-449b-b57f-adec30bf5126@github.com>

On Tue, 10 May 2022 16:30:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
>> 
>> It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
>
>> > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
>> 
>> It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> 
> I think this would be OK, but would get to get someone from our security team to bless it.  
> 
> It might not be a bad idea to add a method to return the name as a String.  There are a couple of places where we do a new String(name) so would economize any future changes

> > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> > > 
> > > 
> > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> > 
> > 
> > I think this would be OK, but would get to get someone from our security team to bless it.
> > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes
> 
> Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.

Already did ;-)   so hopefully they will share their thoughts soon.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From lancea at openjdk.java.net  Tue May 10 17:02:47 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 10 May 2022 17:02:47 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
Message-ID: <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>

On Tue, 10 May 2022 16:51:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I think this would be OK, but would get to get someone from our security team to bless it.
> 
> It's print the entry name, I don't think it is leaking the file path to the zip file.

I think you are probably right I am probably being overly cautious

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From lancea at openjdk.java.net  Tue May 10 17:02:48 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 10 May 2022 17:02:48 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
Message-ID: <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>

On Tue, 10 May 2022 16:58:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> I think this would be OK, but would get to get someone from our security team to bless it.
>> 
>> It's print the entry name, I don't think it is leaking the file path to the zip file.
>
>> > I think this would be OK, but would get to get someone from our security team to bless it.
>> 
>> It's print the entry name, I don't think it is leaking the file path to the zip file.
> 
> I think you are probably right I am probably being overly cautious

> > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> > > > 
> > > > 
> > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> > > 
> > > 
> > > I think this would be OK, but would get to get someone from our security team to bless it.
> > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes
> > 
> > 
> > Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.
> 
> Already did ;-) so hopefully they will share their thoughts soon.

I think it would probably be good for a separate PR for the ZipFS change as it keeps it a bit clearer

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From joehw at openjdk.java.net  Tue May 10 17:07:55 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 10 May 2022 17:07:55 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v6]
In-Reply-To: <EEovBYT0vNoGAm-jZeelZrHUTwQKBVx8lFqEHI37cr0=.5f40c591-a9a3-452c-acdf-31c001b083be@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <EEovBYT0vNoGAm-jZeelZrHUTwQKBVx8lFqEHI37cr0=.5f40c591-a9a3-452c-acdf-31c001b083be@github.com>
Message-ID: <15c391p_sLUHIstEFFJ6GLog6tbubJu_3p6IiQG9Y7A=.949808f1-b30a-4a65-97f3-8b06deb7ff80@github.com>

On Tue, 10 May 2022 06:52:00 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header

src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2022, Oracle and/or its affiliates. All rights reserved.

Remove "2019, ", same with other classes. The header (along with the LastModified tag) serves as an indication that you've modified the file. As this is the first of such modification, it just needs to be noted with the year it's done, that is "2022, ".

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From cay.horstmann at gmail.com  Tue May 10 17:10:31 2022
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Tue, 10 May 2022 19:10:31 +0200
Subject: HttpClient has no explicit way of releasing threads
In-Reply-To: <1923982658.23683953.1652189944082.JavaMail.zimbra@u-pem.fr>
References: <CA+DM0AmX9edJxK4Hv5NCsaFh7k4TouQhgmfTsCJg2_NquLCzWw@mail.gmail.com>
 <1923982658.23683953.1652189944082.JavaMail.zimbra@u-pem.fr>
Message-ID: <57c7a43a-6d2f-4a71-d513-09ab0392ed9b@gmail.com>

Il 10/05/2022 15:39, Remi Forax ha scritto:
> You can change the Executor (it's one parameter of the builder) to use whatever executors you want so you can shutdown that executor as you want.
> This should fixed (1).
> 
> Also once you update to Java 19/21, it seems a good scenario to test the executor that spawn virtual threads instead of platform threads.

I am afraid build 19-ea+21-1482 doesn't yet include virtual threads, but 
it's getting close.

Be careful though. The HttpClient.Builder has an enticing method

HttpClient.Builder 	executor?(Executor executor)

which "Sets the executor to be used for asynchronous and dependent tasks."

What this means is anyone's guess, but I know from Heinz Kabutz that 
it's the executor used for the internal workings of the selector 
mechanism. See https://bugs.openjdk.java.net/browse/JDK-8204679. I don't 
think making that a virtual thread does much good.

If you want to spawn a virtual thread to process the request (a good 
idea if the processing blocks), you should use

client.sendAsync(request, responseBodyHandler)
    .thenApplyAsync(HttpResponse::body, executor);

where executor provides virtual threads.

Cheers,

Cay

-- 

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com

From duke at openjdk.java.net  Tue May 10 17:22:49 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 10 May 2022 17:22:49 GMT
Subject: Integrated: 8282701: Use Class.getInterfaces(false) where possible to
 reduce allocation pressure
In-Reply-To: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
References: <JsaM3_P0znKU-aiGn0IfUskTwt8SvKFkqCRLLnJP1qk=.363ff6da-623f-479b-8c23-7a590f1eaede@github.com>
Message-ID: <t1idknsiHD3AEVISO2BQ9gT_2T6jIXmo-CmnPORjnrY=.9e3efd1e-078c-4e21-87c2-975d235bf871@github.com>

On Sat, 5 Mar 2022 13:07:56 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from.

This pull request has now been integrated.

Changeset: 9073a98d
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9073a98d5791dedc5ed4156ec5229164ed1eef50
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure

Reviewed-by: redestad, mchung

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

PR: https://git.openjdk.java.net/jdk/pull/7714

From naoto at openjdk.java.net  Tue May 10 17:38:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 May 2022 17:38:44 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
Message-ID: <WiC6-cxC4sIe-0cu8gZ-yzwGWKcXojd7kV3p0kLUbIs=.8fabcdab-24c0-48d9-ae93-5c8bcfa5b938@github.com>

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

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

  Fixed offsets in milliseconds, added test variations, refined Custom ID definitions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/843e86be..81a806e5

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

  Stats: 13 lines in 2 files changed: 3 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Tue May 10 17:46:55 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 May 2022 17:46:55 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: <s-QyGkoKSvHjirrxqsW1AFBXqmxX_MZw-qZmU8rMi-M=.58872449-58e1-4fc4-9d1a-a5e953ec9b84@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <s-QyGkoKSvHjirrxqsW1AFBXqmxX_MZw-qZmU8rMi-M=.58872449-58e1-4fc4-9d1a-a5e953ec9b84@github.com>
Message-ID: <kkzrEr20m9vKEr8sHN6VH_CAhHbCliUIBTr2zne8beA=.16399796-cb81-4887-82fd-72382af06feb@github.com>

On Tue, 10 May 2022 13:12:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
>
> src/java.base/share/classes/java/util/TimeZone.java line 109:
> 
>> 107:  * <blockquote><pre>
>> 108:  * <a id="NormalizedCustomID"><i>NormalizedCustomID:</i></a>
>> 109:  *         {@code GMT} <i>Sign</i> <i>TwoDigitHours</i> {@code :} <i>Minutes</i> [<i>Seconds</i>]
> 
> Hello Naoto,
> 
> Should this instead be: `... <i>Minutes</i> [{@code :} <i>Seconds</i>]` - i.e. should it have the `:` literal if seconds are present in the custom timezone id?

The colon is included in `Seconds` part below. I changed the part name to `ColonSeconds` to make it clearer.

> src/java.base/share/classes/java/util/TimeZone.java line 543:
> 
>> 541:             return new ZoneInfo(totalSecs == 0 ? "UTC" : GMT_ID + tzid, totalSecs);
>> 542:         } else {
>> 543:             return getTimeZone(tzid, true);
> 
> Before the change in this PR, we used to prefix `GMT` to (non-custom timezone ids) if the timezone id returned by `ZoneId#getId()` started with the `+` or `-` sign, before calling `getTimeZone(modifiedTzid, true)`. 
> With this change, for `ZoneId`s that aren't `ZoneOffset` instance, we now call `getTimeZone(originalTzid, true)`, without first checking/prefixing the id with `GMT`. Is that an intentional change and would that potentially cause `getTimeZone(String, boolean)` to return a different result?

Yes, it is intentional. The `Time-zone IDs` section in the `ZoneId` class description is clear that zone id starting with "+/-" is a `ZoneOffset` instance. Other ZoneIds should have offsets with prefix or region-based ids.

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

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Tue May 10 17:46:58 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 May 2022 17:46:58 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: <ABcvJDzCIRi4XaSaASXbB8fxcJXuyIODjxGO5J9oh0E=.7c7c2beb-bd96-4982-99e0-e19e5d4b2979@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <ABcvJDzCIRi4XaSaASXbB8fxcJXuyIODjxGO5J9oh0E=.7c7c2beb-bd96-4982-99e0-e19e5d4b2979@github.com>
Message-ID: <RfUh38_pnxkBdxx4cK-arebwVhHR1uis66X-RY6qQNE=.db1ef511-da45-4a12-8b51-7e9dae583ee1@github.com>

On Mon, 9 May 2022 22:29:50 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
>
> src/java.base/share/classes/java/util/TimeZone.java line 539:
> 
>> 537:     public static TimeZone getTimeZone(ZoneId zoneId) {
>> 538:         String tzid = zoneId.getId(); // throws an NPE if null
>> 539:         if (zoneId instanceof ZoneOffset zo) {
> 
> I like this because it is much faster than the conversion to ZoneId and parsing it back! It is similar to use of SimpleTimeZone, but this is better as the returned timezone is unmodifiable, correct?

Yes, and it aligns with the other call site (line 588).

> test/jdk/java/util/TimeZone/ZoneOffsetRoundTripTest.java line 43:
> 
>> 41:     private Object[][] testZoneOffsets() {
>> 42:         return new Object[][] {
>> 43:                 {ZoneId.of("Z"), 0},
> 
> I know, `ZoneId.of()` should parse this as a `ZoneOffset` and return a `ZoneOffset` instance, but maybe add also the other string variants with prefix (`ZoneId.of("UTC+00:00:01")` or `ZoneId.of("GMT+00:00:01")` as data items. Maybe also use `ZoneOffset.of()` for the plain zones to be explicit.

Added them except "UTC+...", as it is not recognizable as a Custom ID.

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

PR: https://git.openjdk.java.net/jdk/pull/8606

From darcy at openjdk.java.net  Tue May 10 19:15:50 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 10 May 2022 19:15:50 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v11]
In-Reply-To: <j0El14oLsZ55beIEuFr54t-0_JjGGwWzikd0_NDxrh0=.9c764adf-5e3b-4e51-a74c-d67485589722@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>
 <UkougCywkC6YSJeQRa0G5TCY6H8xZheWyGpZwLUCyqM=.6b53d8f9-b0f8-470b-bfec-368056d706bf@github.com>
 <j0El14oLsZ55beIEuFr54t-0_JjGGwWzikd0_NDxrh0=.9c764adf-5e3b-4e51-a74c-d67485589722@github.com>
Message-ID: <w-zi3c4rCGllt31rWQC8pnk27IfsUTxuRhn0d1hffl8=.cca2c348-999b-4cb4-9211-3e4daffdc3bb@github.com>

On Tue, 10 May 2022 15:50:26 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> `[Float|Double]ToDecimal` do not have access to `AbstractStringBuilder`, so have to fail over `Appendable`, which can throw `IOException` in `append(*)` methods.
> 
> I have to find another way if this wrapping to make the compiler happy is unacceptable.

Ah, I haven't used it myself recently enough to recall the details, but I believe the shared secrets mechanism is intended to allow such cross-package access.

If the current code is kept and if the exception can actually be thrown, explicitly throwing an assertion error is preferable to "assert false".

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

PR: https://git.openjdk.java.net/jdk/pull/3402

From lmesnik at openjdk.java.net  Tue May 10 19:16:34 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 10 May 2022 19:16:34 GMT
Subject: RFR: 8286368: Cleanup problem lists after loom integration [v2]
In-Reply-To: <FGFlG77wBJ_9oPlKFrldqBG_9ixAOGZW6ZHAuEVxkmk=.19ac9767-45f6-4441-89da-66663b9c6e53@github.com>
References: <FGFlG77wBJ_9oPlKFrldqBG_9ixAOGZW6ZHAuEVxkmk=.19ac9767-45f6-4441-89da-66663b9c6e53@github.com>
Message-ID: <Stq8HlCgHVfFJo_AWSLCBbPjK0BsRHMdC7OwyQOC4WI=.18632196-3b50-41de-8412-a7fd7e508e27@github.com>

> 8286368: Cleanup problem lists after loom integration

Leonid Mesnik 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
 - 8286368: Cleanup problem lists after loom integration

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

Changes: https://git.openjdk.java.net/jdk/pull/8604/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8604&range=01
  Stats: 29 lines in 4 files changed: 1 ins; 22 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8604.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8604/head:pull/8604

PR: https://git.openjdk.java.net/jdk/pull/8604

From lmesnik at openjdk.java.net  Tue May 10 19:16:34 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 10 May 2022 19:16:34 GMT
Subject: Integrated: 8286368: Cleanup problem lists after loom integration
In-Reply-To: <FGFlG77wBJ_9oPlKFrldqBG_9ixAOGZW6ZHAuEVxkmk=.19ac9767-45f6-4441-89da-66663b9c6e53@github.com>
References: <FGFlG77wBJ_9oPlKFrldqBG_9ixAOGZW6ZHAuEVxkmk=.19ac9767-45f6-4441-89da-66663b9c6e53@github.com>
Message-ID: <WPc-AldgZNOZeuNdXlG0ErvvIuOGHkGbsdDNx-7CLBU=.9fd945fa-d1f7-45c0-bf1f-732bfdd422a7@github.com>

On Mon, 9 May 2022 18:17:13 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> 8286368: Cleanup problem lists after loom integration

This pull request has now been integrated.

Changeset: dcec1d2a
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dcec1d2a68e2c82e27174c3dc52bb17316530966
Stats:     29 lines in 4 files changed: 1 ins; 22 del; 6 mod

8286368: Cleanup problem lists after loom integration

Reviewed-by: alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8604

From duke at openjdk.java.net  Tue May 10 19:27:50 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Tue, 10 May 2022 19:27:50 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com>
Message-ID: <VijngstCNgus5frNVxsXNltFrk6gkcjOv8iBYfcrVls=.bf4f6194-de7f-467b-b5c0-88316be89289@github.com>

On Fri, 6 May 2022 17:56:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JDK-6725221 Standardize obtaining boolean properties with defaults
>
> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777:
> 
>> 775:         if (!printStackPropertiesSet && VM.initLevel() >= 1) {
>> 776:             printStackWhenAccessFails = GetBooleanAction.
>> 777:                 privilegedGetProperty("sun.reflect.debugModuleAccessChecks");
> 
> Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false.

You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes.

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

PR: https://git.openjdk.java.net/jdk/pull/8559

From alanb at openjdk.java.net  Tue May 10 20:02:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 20:02:48 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
Message-ID: <dPmSVzIHGfwcmaJTIGwDS6O9Ppl0QAcBYbGDwqaFDJU=.480f6a7b-5da5-4fc9-8e13-2c678e605465@github.com>

On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
> 
> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
> 
> I also cleaned up related code in the JDK and HotSpot.
> 
> Testing:
> - Passed tiers 1 and 2
> - Tiers 3, 4, 5 are in progress

src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java line 60:

> 58:             FileChannel fc = new RandomAccessFile(f, "r").getChannel();
> 59:             ByteBuffer bb = fc.map(FileChannel.MapMode.READ_ONLY, 0L, (int)fc.size());
> 60:             fc.close();               // doesn't need to remain open

I think you can change this to:


        try (FileChannel fc = FileChannel.open(f.toPath())) {
            ByteBuffer bb = ...
            createPerfDataBuffer(bb, 0);
        }

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From alanb at openjdk.java.net  Tue May 10 20:06:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 May 2022 20:06:47 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
Message-ID: <fJVbOoDRaDA37EScdewg0G4nCyTzYZ2M4ZXWY_ubpoQ=.1be2132e-0af9-4a36-a9ee-33cc182f745d@github.com>

On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
> 
> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
> 
> I also cleaned up related code in the JDK and HotSpot.
> 
> Testing:
> - Passed tiers 1 and 2
> - Tiers 3, 4, 5 are in progress

I skimmed through the changes and I think they look okay. In the distant past there were tools outside of the JDK that used the jvmstat API directly. It's possible that VisualVM still does but it would only compile/run if --add-exports is used to export the sun.jvmstat.* packages. So it might be that dropping the parameter from a method in RemoteHost is noticed and I think that is okay because this package is not exported and is not meant to be used by code outside of the JDK.

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From naoto at openjdk.java.net  Tue May 10 20:30:19 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 May 2022 20:30:19 GMT
Subject: RFR: 8286287: Reading file as UTF-16 causes Error which
 "shouldn't happen"
Message-ID: <oCWtLqDR1Wh8DCeIeCdLExXp9JXEPZ2LMODfe0FDaZs=.03d127d4-316d-4be0-96fc-fbfe61031dd4@github.com>

`String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter replaces on malformed/unmappable characters with replacements. However, there was a code path that lacked to set the `CodingErrorAction.REPLACE` on the decoder. Unrelated, one typo in a test was also fixed.

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

Commit messages:
 - 8286287: Reading file as UTF-16 causes Error which "shouldn't happen"

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

PR: https://git.openjdk.java.net/jdk/pull/8640

From vlivanov at openjdk.java.net  Tue May 10 21:06:18 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 10 May 2022 21:06:18 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
Message-ID: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>

On Mon, 9 May 2022 10:28:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
>> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
>> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
>> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>  - Remove unneeded ComputeMoveOrder
>  - Remove comment about native calls in lcm.cpp
>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>    
>    Reviewed-by: jvernee, mcimadamore
>  - Update riscv and arm stubs
>  - Remove spurious ProblemList change
>  - Pass pointer to LogStream
>  - Polish
>  - Replace TraceNativeInvokers flag with unified logging
>  - Fix other platforms, take 2
>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91

Nice work! Looks good. Some minor comments/questions follow.

src/hotspot/cpu/aarch64/frame_aarch64.cpp line 379:

> 377:   // need unextended_sp here, since normal sp is wrong for interpreter callees
> 378:   return reinterpret_cast<OptimizedEntryBlob::FrameData*>(
> 379:     reinterpret_cast<char*>(frame.unextended_sp()) + in_bytes(_frame_data_offset));

Maybe use `address` instead of `char*`?

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531:

> 5529: }
> 5530: 
> 5531: // On 64 bit we will store integer like items to the stack as

Time for a cleanup? `64 bit` vs `64bit`, `abi`, `Aarch64`.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5547:

> 5545:   } else if (dst.first()->is_stack()) {
> 5546:     // reg to stack
> 5547:     // Do we really have to sign extend???

Obsolete? Remove?

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306:

> 304:   intptr_t exception_handler_offset = __ pc() - start;
> 305: 
> 306:   // Native caller has no idea how to handle exceptions,

Can you elaborate, please, how it is expected to work in presence of asynchronous exceptions? I'd expect to see a code which unconditionally clears pending exception with an assertion that verifies that the exception is of expected type.

src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30:

> 28: #include "utilities/growableArray.hpp"
> 29: 
> 30: class outputStream;

Redundant declaration?

src/hotspot/cpu/x86/foreign_globals_x86_64.cpp line 52:

> 50: 
> 51:   objArrayOop inputStorage = jdk_internal_foreign_abi_ABIDescriptor::inputStorage(abi_oop);
> 52:   loadArray(inputStorage, INTEGER_TYPE, abi._integer_argument_registers, as_Register);

`loadArray` helper looks a bit misleading. In presence of `javaClass`-style accessors, it misleadingly hints that it refers to some Java-level operation/entity, though what it does it parses register list representation backed by a Java array. I suggest to rename it to something like `parse_argument_registers_array()`).

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933:

> 931:     } else {
> 932:       assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)",
> 933:        src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name());

Wrong indentation.

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 36:

> 34: #include "code/nativeInst.hpp"
> 35: #include "code/vtableStubs.hpp"
> 36: #include "compiler/disassembler.hpp"

Redundant includes? No new code added in the file.

src/hotspot/share/c1/c1_GraphBuilder.cpp line 4230:

> 4228: 
> 4229:   case vmIntrinsics::_linkToNative:
> 4230:     print_inlining(callee, "Native call", /*success*/ false);

Since the message is appended, lower case is preferred:`"native call"`.

src/hotspot/share/code/codeBlob.hpp line 754:

> 752: class ProgrammableUpcallHandler;
> 753: 
> 754: class OptimizedEntryBlob: public RuntimeBlob {

What's the motivation to move `OptimizedEntryBlob` up in the hierarchy (from `BufferBlob` to `RuntimeBlob`)?

src/hotspot/share/opto/callGenerator.cpp line 1131:

> 1129: 
> 1130:     case vmIntrinsics::_linkToNative:
> 1131:     print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(),

Why is it unconditionally reported as inlining failure?

src/hotspot/share/prims/foreign_globals.cpp line 147:

> 145: // based on ComputeMoveOrder from x86_64 shared runtime code.
> 146: // with some changes.
> 147: class ForeignCMO: public StackObj {

Considering how seldom it is used, I don't see much value in abbreviating it. Also, the comment is misleading: there's no such entity as `ComputeMoveOrder` in the code. And `compute_move_order` is completely removed by this change.

src/hotspot/share/prims/foreign_globals.cpp line 217:

> 215: 
> 216:  public:
> 217:   ForeignCMO(int total_in_args, const VMRegPair* in_regs, int total_out_args, VMRegPair* out_regs,

I propose to turn it into a trivial ctor and move all the logic into a helper static function which returns the computed moves.

src/hotspot/share/prims/foreign_globals.hpp line 35:

> 33: #include CPU_HEADER(foreign_globals)
> 34: 
> 35: class CallConvClosure {

Just a question on terminology: why is it called a `Closure`?

src/hotspot/share/prims/foreign_globals.hpp line 62:

> 60: 
> 61: 
> 62: class JavaCallConv : public CallConvClosure {

Does it really worth to abbreviate `CallingConvention` to `CallConv`?

src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 313:

> 311:         MethodType newType = oldType.dropParameterTypes(destIndex, destIndex + 1);
> 312:         int[] reorder = new int[oldType.parameterCount()];
> 313:         if (destIndex < sourceIndex)

Misses braces.

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Architecture.java line 169:

> 167:             stackAlignment,
> 168:             shadowSpace,
> 169:                 targetAddrStorage, retBufAddrStorage);

Wrong indentation.

src/java.base/share/classes/jdk/internal/foreign/abi/x64/X86_64Architecture.java line 156:

> 154:             stackAlignment,
> 155:             shadowSpace,
> 156:                 targetAddrStorage, retBufAddrStorage);

Wrong indentation.

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From vlivanov at openjdk.java.net  Tue May 10 21:06:20 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 10 May 2022 21:06:20 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <SSI4EbbwAEFokP_lQ3ET9TZRNzxEC6DHZ2_hvQft3eo=.70763ae0-6260-40f7-99d5-6bd151a70ee4@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <SSI4EbbwAEFokP_lQ3ET9TZRNzxEC6DHZ2_hvQft3eo=.70763ae0-6260-40f7-99d5-6bd151a70ee4@github.com>
Message-ID: <F0kIhISiVv7a-ST9aj9bMEe7o3kXcGdYcaL8TLj6o5Y=.623c3848-179d-4dee-8ea2-61cf185a8a2d@github.com>

On Mon, 28 Mar 2022 12:15:10 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/share/utilities/growableArray.hpp line 151:
> 
>> 149:     return _data;
>> 150:   }
>> 151: 
> 
> This accessor is added to be able to temporarily view a stable GrowableArray instance as a C-style array. It is used to by `NativeCallConv` and `RegSpiller` in `foreign_globals.hpp`.
> 
> GrowableArray already has an `adr_at` accessor that does something similar, but using `adr_at(0)` fails on empty growable arrays since it also performs a bounds check. So it can not be used.

Any problems with migrating `CallConv` and `RegSpiller`away from ` VMReg* + int` to `GrowableArray<VMReg>`?

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From mullan at openjdk.java.net  Tue May 10 21:30:02 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 10 May 2022 21:30:02 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
 <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
Message-ID: <hgUaDRzCG63uA_pqcKpRkjqbaYIxnItBMEGalLq0nfY=.0f7cf288-f2c0-4e3f-99d6-d040fa3ab90e@github.com>

On Tue, 10 May 2022 16:59:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > > > > @LanceAndersen @AlanBateman do you think adding the entry name in the exception in ZipFileSystem is ok? If so, should it maybe go into a different patch?
> > > > 
> > > > 
> > > > It should be okay as this is the name of an entry in the zip file. It might be a bit cleaner to add a method to IndexNode to return the name as String. Alternatively maybe its toString could be changed to drop the index (I would need to dig into the history to find out if there is really any use for the index in the String representation).
> > > 
> > > 
> > > I think this would be OK, but would get to get someone from our security team to bless it.
> > > It might not be a bad idea to add a method to return the name as a String. There are a couple of places where we do a new String(name) so would economize any future changes
> > 
> > 
> > Sounds fair. @LanceAndersen, can you please ask the security team about their ok then and let me know? In case their answer is a yes, I'll work on implementing the suggestion to return the name as String. Shall I maybe do the zipfs change in a different PR then? The more important change in the context of javac is printing out the jar name in javac itself.
> 
> Already did ;-) so hopefully they will share their thoughts soon.

It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message?

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From mullan at openjdk.java.net  Tue May 10 21:33:50 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 10 May 2022 21:33:50 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <hgUaDRzCG63uA_pqcKpRkjqbaYIxnItBMEGalLq0nfY=.0f7cf288-f2c0-4e3f-99d6-d040fa3ab90e@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
 <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
 <hgUaDRzCG63uA_pqcKpRkjqbaYIxnItBMEGalLq0nfY=.0f7cf288-f2c0-4e3f-99d6-d040fa3ab90e@github.com>
Message-ID: <LK0Wm2DH5Bk474DqMvsnMPzB0IWGfEEukSXZTHzZEiY=.a1733ce2-0540-41fe-b3fc-db54f9a4a38b@github.com>

On Tue, 10 May 2022 21:26:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message?

The bug report also says "The error message does not give a clue which jar file is causing the problem" but the error message includes the name "invalid.jar" so I am also confused about that.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From rriggs at openjdk.java.net  Tue May 10 21:38:19 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 10 May 2022 21:38:19 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base
Message-ID: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>

PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>From the CSR:

"If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."

This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
Since these casts are truncating the value, there might be a different refactoring that avoids the cast
but a direct replacement was chosen here.

(Advise and suggestions will inform similar updates to other OpenJDK modules).

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

Commit messages:
 - 8286378: Address possibly lossy conversions in java.base

Changes: https://git.openjdk.java.net/jdk/pull/8642/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286378
  Stats: 57 lines in 33 files changed: 1 ins; 3 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642

PR: https://git.openjdk.java.net/jdk/pull/8642

From redestad at openjdk.java.net  Tue May 10 21:47:50 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 10 May 2022 21:47:50 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
Message-ID: <5AjTeD3XkuyBV8Dux7QVRkJgDwTiJ4Et9303eiMLjNU=.84477522-bbdb-4215-976f-729910707634@github.com>

On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
> 
> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
> 
> I also cleaned up related code in the JDK and HotSpot.
> 
> Testing:
> - Passed tiers 1 and 2
> - Tiers 3, 4, 5 are in progress

Nice cleanup!

(Some stylistic suggestions inline, feel free to ignore)

src/hotspot/os/windows/perfMemory_windows.cpp line 1781:

> 1779: // address space.
> 1780: //
> 1781: void PerfMemory::attach(const char* user, int vmid,

One line?

src/hotspot/share/prims/perf.cpp line 84:

> 82: 
> 83:   // attach to the PerfData memory region for the specified VM
> 84:   PerfMemory::attach(user_utf, vmid,

One line?

src/hotspot/share/runtime/perfMemory.hpp line 146:

> 144:     // methods for attaching to and detaching from the PerfData
> 145:     // memory segment of another JVM process on the same system.
> 146:     static void attach(const char* user, int vmid,

One line?

src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java line 74:

> 72:         Integer v = lvmid;
> 73:         RemoteVm stub = null;
> 74:         StringBuilder sb = new StringBuilder();

Suggestion:

        String vmidStr = "local://" + lvmid + "@localhost";

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

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8622

From naoto at openjdk.java.net  Tue May 10 22:02:49 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 May 2022 22:02:49 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <zCrdVr1pkcm4Awm7gTH7s6oXP6GeF7Sj9GLgvCnG5tY=.58c9151b-d43a-4c2b-9276-1dcbe603ef05@github.com>

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

Looks good. Assuming copyright years will be updated.

src/java.base/share/classes/java/time/es line 1:

> 1: X

Looks like a random file was added by accident?

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8642

From xuelei at openjdk.java.net  Tue May 10 22:16:47 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 10 May 2022 22:16:47 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <7lDCcjqL3nlin4_E8rebEkaoQ96_Tz2jbarFVJVF3PY=.88a6da8e-6f79-4889-88f3-4248037609e1@github.com>

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

The update in security area looks good to me.

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

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8642

From vromero at openjdk.java.net  Tue May 10 22:49:53 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 10 May 2022 22:49:53 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v5]
In-Reply-To: <MYQYuhBdAWz5laM3hVrIlVC7KJQE38AJ-Y-lPbw-mP0=.ef02fbe6-bfc5-49e0-8e30-712c187b0f6c@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <MYQYuhBdAWz5laM3hVrIlVC7KJQE38AJ-Y-lPbw-mP0=.ef02fbe6-bfc5-49e0-8e30-712c187b0f6c@github.com>
Message-ID: <Fz6ZOwDacA_o-vFe2JLgKK206dac6I-mqPjmZgavzVs=.f8fede3b-e27d-41ba-bc74-0fff66479ac4@github.com>

On Tue, 10 May 2022 09:57:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing (non-)exhaustiveness for enum.

looks good to me, great job!

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

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8516

From bpb at openjdk.java.net  Tue May 10 22:57:49 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 10 May 2022 22:57:49 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <7I3Y3hwAO8Sirtab0JkW7SPyjqZlDAhGciKVD47qXOE=.22ddd9bd-1491-4b39-94ed-de1977181c1f@github.com>

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

IO, math, and NIO changes look fine.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8642

From rriggs at openjdk.java.net  Tue May 10 23:01:33 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 10 May 2022 23:01:33 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2]
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <YNg7_xSMNKVRomOPRtRyyPsWSSu4Rdv28n0XOW_6xfs=.e550ad3b-66b9-417a-bff4-9ef57da7997b@github.com>

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

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

  remove stray file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8642/files
  - new: https://git.openjdk.java.net/jdk/pull/8642/files/e72ce85c..7ff806a5

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

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From 987140074 at qq.com  Wed May 11 01:58:43 2022
From: 987140074 at qq.com (=?ISO-8859-1?B?OTg3MTQwMDc0?=)
Date: Wed, 11 May 2022 09:58:43 +0800
Subject: httpsserver
Message-ID: <tencent_3316E889E70655899737EA198E10E55E6207@qq.com>

hello,i have a problem when using com.sun.net.httpsserver.Httpsserver as the Httpsserver connections with device.The jdk version is 8,and the method is create(InetsocketAddress addr, &nbsp;int backlog).Expect to get your answer.
The problem is as follows:
When i attack the Httpsserver by sending &nbsp;TCP connections continuously,the TCP connection to the Httpsserver listening port keeps increasing,about 7000 connections.In extreme scenarios,service functions are unavailable.
Have you identified this problem.When com.sun.net.httpsserver.Httpsserver is used,can this type of attack be defended.
Looking forward to your reply.

From iklam at openjdk.java.net  Wed May 11 02:43:21 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 02:43:21 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
Message-ID: <nJ3YUlzlAvMknJJxLkByfKxWQJ-2vYUFhJhC4DRyrCY=.9e4b5a6b-69cd-4792-89dc-94b3b1664d99@github.com>

> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
> 
> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
> 
> I also cleaned up related code in the JDK and HotSpot.
> 
> Testing:
> - Passed tiers 1 and 2
> - Tiers 3, 4, 5 are in progress

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

  review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8622/files
  - new: https://git.openjdk.java.net/jdk/pull/8622/files/22c22c30..34a01f71

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

  Stats: 14 lines in 5 files changed: 1 ins; 7 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8622.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8622/head:pull/8622

PR: https://git.openjdk.java.net/jdk/pull/8622

From iklam at openjdk.java.net  Wed May 11 02:43:24 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 02:43:24 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <5AjTeD3XkuyBV8Dux7QVRkJgDwTiJ4Et9303eiMLjNU=.84477522-bbdb-4215-976f-729910707634@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
 <5AjTeD3XkuyBV8Dux7QVRkJgDwTiJ4Et9303eiMLjNU=.84477522-bbdb-4215-976f-729910707634@github.com>
Message-ID: <h_uM9CtM8JppYGlFDCZ6-xLM2MWY7kB2K6yuFrwzCvU=.ae2e89b3-2862-48ba-82a9-17bfcc37d777@github.com>

On Tue, 10 May 2022 21:43:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> src/hotspot/os/windows/perfMemory_windows.cpp line 1781:
> 
>> 1779: // address space.
>> 1780: //
>> 1781: void PerfMemory::attach(const char* user, int vmid,
> 
> One line?

Fixed

> src/hotspot/share/prims/perf.cpp line 84:
> 
>> 82: 
>> 83:   // attach to the PerfData memory region for the specified VM
>> 84:   PerfMemory::attach(user_utf, vmid,
> 
> One line?

Fixed

> src/hotspot/share/runtime/perfMemory.hpp line 146:
> 
>> 144:     // methods for attaching to and detaching from the PerfData
>> 145:     // memory segment of another JVM process on the same system.
>> 146:     static void attach(const char* user, int vmid,
> 
> One line?

Fixed

> src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java line 74:
> 
>> 72:         Integer v = lvmid;
>> 73:         RemoteVm stub = null;
>> 74:         StringBuilder sb = new StringBuilder();
> 
> Suggestion:
> 
>         String vmidStr = "local://" + lvmid + "@localhost";

Fixed

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From iklam at openjdk.java.net  Wed May 11 02:43:25 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 02:43:25 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <dPmSVzIHGfwcmaJTIGwDS6O9Ppl0QAcBYbGDwqaFDJU=.480f6a7b-5da5-4fc9-8e13-2c678e605465@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
 <dPmSVzIHGfwcmaJTIGwDS6O9Ppl0QAcBYbGDwqaFDJU=.480f6a7b-5da5-4fc9-8e13-2c678e605465@github.com>
Message-ID: <BMNhbA9nWHe8hI992LIuX9duAoUDuVQjuvA5iJRG1I4=.39fc8993-d6ce-4019-ae82-2eb190c36683@github.com>

On Tue, 10 May 2022 19:59:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java line 60:
> 
>> 58:             FileChannel fc = new RandomAccessFile(f, "r").getChannel();
>> 59:             ByteBuffer bb = fc.map(FileChannel.MapMode.READ_ONLY, 0L, (int)fc.size());
>> 60:             fc.close();               // doesn't need to remain open
> 
> I think you can change this to:
> 
> 
>         try (FileChannel fc = FileChannel.open(f.toPath())) {
>             ByteBuffer bb = ...
>             createPerfDataBuffer(bb, 0);
>         }

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From iklam at openjdk.java.net  Wed May 11 02:52:47 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 02:52:47 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <fJVbOoDRaDA37EScdewg0G4nCyTzYZ2M4ZXWY_ubpoQ=.1be2132e-0af9-4a36-a9ee-33cc182f745d@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
 <fJVbOoDRaDA37EScdewg0G4nCyTzYZ2M4ZXWY_ubpoQ=.1be2132e-0af9-4a36-a9ee-33cc182f745d@github.com>
Message-ID: <t8HcObumyWDO7DRRif0BR4CLXxRE921QnzaVcUlYUew=.c26c55ad-a64a-4198-97d2-c3db486ba9c7@github.com>

On Tue, 10 May 2022 20:03:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I skimmed through the changes and I think they look okay. In the distant past there were tools outside of the JDK that used the jvmstat API directly. It's possible that VisualVM still does but it would only compile/run if --add-exports is used to export the sun.jvmstat.* packages. So it might be that dropping the parameter from a method in RemoteHost is noticed and I think that is okay because this package is not exported and is not meant to be used by code outside of the JDK.

The APIs changed by this PR are:

- sun.jvmstat.monitor.remote.RemoteHost::attachVm
- sun.jvmstat.monitor.VmIdentifier::getMode
- sun.jvmstat.monitor.HostIdentifier::getMode
- jdk.internal.perf.Perf::attach

I checked the latest VisualVM source code. Some of the above classes are referenced, but none of the affected APIs are called.

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

PR: https://git.openjdk.java.net/jdk/pull/8622

From xgong at openjdk.java.net  Wed May 11 03:26:57 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 11 May 2022 03:26:57 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <PAbHd6tldh6Is0PsXN3l5gzVGugeU9aXERzFEdFOWCE=.c19b875b-50ec-4c08-a75d-cd23d27e2bfa@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <PAbHd6tldh6Is0PsXN3l5gzVGugeU9aXERzFEdFOWCE=.c19b875b-50ec-4c08-a75d-cd23d27e2bfa@github.com>
Message-ID: <Z8meMXznUI2sBBFeON_F668Mq46tMOiRRkSnyu99igA=.ec466e89-bca0-4e54-8974-e6fc708ace49@github.com>

On Mon, 9 May 2022 21:55:27 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename "use_predicate" to "needs_predicate"
>
> I modified the code of this PR to avoid the conversion of `boolean` to `int`, so a constant integer value is passed all the way through, and the masked load is made intrinsic from the method at which the constants are passed as arguments i.e. the public `fromArray` mask accepting method.

Hi @PaulSandoz , thanks for the patch for the constant int parameter. I think the main change is:

-    ByteVector fromArray0Template(Class<M> maskClass, C base, long offset, int index, M m, boolean offsetInRange,
+    ByteVector fromArray0Template(Class<M> maskClass, C base, long offset, int index, M m, int offsetInRange,
                         VectorSupport.LoadVectorMaskedOperation<C, ByteVector, ByteSpecies, M> defaultImpl) {
         m.check(species());
         ByteSpecies vsp = vspecies();
-        if (offsetInRange) {
-            return VectorSupport.loadMasked(
-                vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(),
-                base, offset, m, /* offsetInRange */ 1,
-                base, index, vsp, defaultImpl);
-        } else {
-            return VectorSupport.loadMasked(
-                vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(),
-                base, offset, m, /* offsetInRange */ 0,
-                base, index, vsp, defaultImpl);
-        }
+        return VectorSupport.loadMasked(
+            vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(),
+            base, offset, m, offsetInRange == 1 ? 1 : 0,
+            base, index, vsp, defaultImpl);
     }

which uses `offsetInRange == 1 ? 1 : 0`. Unfortunately this could not always make sure the `offsetInRange` a constant a the compiler time. Again, this change could also make the assertion fail randomly:

--- a/src/hotspot/share/opto/vectorIntrinsics.cpp
+++ b/src/hotspot/share/opto/vectorIntrinsics.cpp
@@ -1236,6 +1236,7 @@ bool LibraryCallKit::inline_vector_mem_masked_operation(bool is_store) {
     } else {
       // Masked vector load with IOOBE always uses the predicated load.
       const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int();
+      assert(offset_in_range->is_con(), "must be a constant");
       if (!offset_in_range->is_con()) {
         if (C->print_intrinsics()) {
           tty->print_cr("  ** missing constant: offsetInRange=%s",

Sometimes, the compiler can parse it a constant. I think this depends on the compiler OSR and speculative optimization. Did you try an example with IOOBE on a non predicated hardware?

Here is the main code of my unittest to reproduce the issue:

static final VectorSpecies<Integer> I_SPECIES = IntVector.SPECIES_128;
static final int LENGTH = 1026;
public static int[] ia;
public static int[] ib;

private static void init() {
        for (int i = 0; i < LENGTH; i++) {
            ia[i] = i;
            ib[i] = 0;
        }

        for (int i = 0; i < 2; i++) {
            m[i] = i % 2 == 0;
        }
}

 private static void func() {
        VectorMask<Integer> mask = VectorMask.fromArray(I_SPECIES, m, 0);
        for (int i = 0; i < LENGTH; i += vl) {
            IntVector av = IntVector.fromArray(I_SPECIES, ia, i, mask);
            av.lanewise(VectorOperators.ABS).intoArray(ic, i, mask);
        }
 }

 public static void main(String[] args) {
        init();
        for (int i = 0; i < 10000; i++) {
            func();
        }
  }

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

PR: https://git.openjdk.java.net/jdk/pull/8035

From duke at openjdk.java.net  Wed May 11 05:22:22 2022
From: duke at openjdk.java.net (Shruthi)
Date: Wed, 11 May 2022 05:22:22 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v7]
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <-r3ALnm_qKjys-U2GxzdJykWJUglWqMdBglBPdmiBKs=.b8664eec-5cdc-4e6c-85f4-6c48bd393d78@github.com>

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

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

  Modify copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8318/files
  - new: https://git.openjdk.java.net/jdk/pull/8318/files/0cf1f9b9..283f8ef9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=05-06

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

PR: https://git.openjdk.java.net/jdk/pull/8318

From alanb at openjdk.java.net  Wed May 11 05:26:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 05:26:39 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2]
In-Reply-To: <YNg7_xSMNKVRomOPRtRyyPsWSSu4Rdv28n0XOW_6xfs=.e550ad3b-66b9-417a-bff4-9ef57da7997b@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <YNg7_xSMNKVRomOPRtRyyPsWSSu4Rdv28n0XOW_6xfs=.e550ad3b-66b9-417a-bff4-9ef57da7997b@github.com>
Message-ID: <KkBl61XjKZOSpP2maNzaPqPMvLJX_g6gT7wut_06Jq4=.136be44a-5c06-477d-9128-013cd0936574@github.com>

On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove stray file

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:

> 126:                     // timed poll interrupted so need to adjust timeout
> 127:                     long adjust = System.nanoTime() - startTime;
> 128:                     to -= (int)TimeUnit.MILLISECONDS.convert(adjust, TimeUnit.NANOSECONDS);

Can we change this `to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);` while we here?

src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java line 615:

> 613:         if (outputStackTop >= elements) {
> 614:             outputStackTop -= (short)elements;
> 615:         } else {

I think we usually try to avoid changing the ASM code if possible but maybe you have to do this because the compiler option is used for compiling java.base?

src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java line 123:

> 121:                     // timed poll interrupted so need to adjust timeout
> 122:                     long adjust = System.nanoTime() - startTime;
> 123:                     to -= (int)TimeUnit.MILLISECONDS.convert(adjust, TimeUnit.NANOSECONDS);

This one can also be changed to:

`to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);`

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From shade at openjdk.java.net  Wed May 11 05:31:45 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 11 May 2022 05:31:45 GMT
Subject: RFR: 8286474: Drop --enable-preview from Sealed Classes related
 tests [v2]
In-Reply-To: <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>
References: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
 <Cc-AKc6owUMDGJ_pDFiQYQwZOfrZKr_SJrlImcxtNdg=.bfecadc1-9906-4e6d-baff-26e3ea27e0c5@github.com>
Message-ID: <qCHTnLXXeCaShX9m7zGuAAQ7toL_Osmzh-EQDoMrEz0=.cb34a8bc-c38d-46dd-8f88-ad43e8887079@github.com>

On Tue, 10 May 2022 14:58:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the Sealed Classes tests, since Sealed Classes have been graduated from preview in JDK 17.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x] Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From shade at openjdk.java.net  Wed May 11 05:31:45 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 11 May 2022 05:31:45 GMT
Subject: Integrated: 8286474: Drop --enable-preview from Sealed Classes related
 tests
In-Reply-To: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
References: <ney2I13cKy0wAYcm1-9iQUURAiD8ZzzIzFuhbJ3sxSo=.7578e38e-65e7-4a12-b25d-bc7a87d2ab38@github.com>
Message-ID: <MUv4FaCyyhD0mKcI2DyKv1fY_FxyZ62j3MHxXTLfYzs=.7a422c5f-2d0e-438b-b861-724392f30a54@github.com>

On Tue, 10 May 2022 12:07:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvement eliminates some of the redundant `--enable-preview` clauses from the Sealed Classes tests, since Sealed Classes have been graduated from preview in JDK 17.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, affected tests still pass
>  - [x] Linux x86_32 fastdebug, affected tests start to pass

This pull request has now been integrated.

Changeset: d547a707
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d547a707bf1f9e252213fdab7eaf076b5cf884b4
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8286474: Drop --enable-preview from Sealed Classes related tests

Reviewed-by: alanb, jpai, mchung, lancea

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

PR: https://git.openjdk.java.net/jdk/pull/8627

From alanb at openjdk.java.net  Wed May 11 05:42:36 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 05:42:36 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <LK0Wm2DH5Bk474DqMvsnMPzB0IWGfEEukSXZTHzZEiY=.a1733ce2-0540-41fe-b3fc-db54f9a4a38b@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
 <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
 <hgUaDRzCG63uA_pqcKpRkjqbaYIxnItBMEGalLq0nfY=.0f7cf288-f2c0-4e3f-99d6-d040fa3ab90e@github.com>
 <LK0Wm2DH5Bk474DqMvsnMPzB0IWGfEEukSXZTHzZEiY=.a1733ce2-0540-41fe-b3fc-db54f9a4a38b@github.com>
Message-ID: <EjOkZaKwGMRD7tnv8j2dz1V0neykKG6-ag38tfobH-Q=.7d114b54-be20-46c4-b3c7-f1dc6e774b8e@github.com>

On Tue, 10 May 2022 21:30:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message?
> 
> The bug report also says "The error message does not give a clue which jar file is causing the problem" but the error message includes the name "invalid.jar" so I am also confused about that.

There are two parts to it. In the case of initCEN method, the proposed change is to include the name of the rejected entry in the exception message. This is not the same thing as leaking a file path in the exception message so I don't think we have a concern here.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From ysuenaga at openjdk.java.net  Wed May 11 06:03:58 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 11 May 2022 06:03:58 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings
Message-ID: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>

I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
As you can see, the warnings spreads several areas. Let me know if I should separate them by area.

* -Wstringop-overflow
    * src/hotspot/share/oops/array.hpp
    * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp

In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
    inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
    inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
    inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

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

Commit messages:
 - 8286562: GCC 12 reports some compiler warnings

Changes: https://git.openjdk.java.net/jdk/pull/8646/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286562
  Stats: 63 lines in 13 files changed: 51 ins; 1 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646

PR: https://git.openjdk.java.net/jdk/pull/8646

From jrose at openjdk.java.net  Wed May 11 06:28:37 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 11 May 2022 06:28:37 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v2]
In-Reply-To: <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <umZcmzwHYP-3A50ORfu4n9EQ-kqvn7zwJMjn3aTJbLM=.a4c996d0-d373-4233-9b81-259905dcfd7f@github.com>
Message-ID: <sISfnxp1FBO9eR2lfA8D57iqvW-Xq2VFduvRezba1ok=.74a7448d-7f76-4be8-9180-d8b479d56c03@github.com>

On Tue, 10 May 2022 09:07:44 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8244681: Add a warning for possibly lossy conversion in compound assignments
>   recommended correction of the warning wording
>   fixed typo in test method name

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 210:

> 208: 
> 209: javac.opt.Xlint.desc.lossy-conversions=\
> 210:     Warn about compiler possible lossy conversions.

I like this warning.  But the documentation doesn't even parse as English.

I suggest this, as more grammatical and precise:

> Warn about possible lossy conversions in compound assignments

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From duke at openjdk.java.net  Wed May 11 06:52:59 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 11 May 2022 06:52:59 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v12]
In-Reply-To: <PP7oByBGJce2DZZTe_1W4dtmld2cYUyBj-MiJEo0E58=.904b7b82-0333-4520-918b-0314f0e8fa3a@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
 <PP7oByBGJce2DZZTe_1W4dtmld2cYUyBj-MiJEo0E58=.904b7b82-0333-4520-918b-0314f0e8fa3a@github.com>
Message-ID: <9la0z1sKAQV3hVIEQUidQMmYSMmgZl-b3huvEUGwa4s=.1bcf6ea2-d008-4b63-834f-4a7e1829a62b@github.com>

On Tue, 10 May 2022 14:46:56 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
>> 
>> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
>> 
>> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
>> 
>> 
>> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
>> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
>> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
>> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
>> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
>> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
>> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
>> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
>> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
>> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
>> 
>> 
>> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
>> 
>> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf
>
> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Fix overlapping registers
>  - Actually fix h when hashcode is vectorized
>  - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
>  - Fix h when vectorized for Arrays.hashCode
>  - Add missing check for AryHashCode node
>  - Fix some merge conflicts
>  - Disable Arrays.hashCode intrinsic by default for CI
>  - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
>  - Some small refactoring: store power_of_31_backwards in the code directly, compact code, and more
>  - {wip} Generalize string hashcode to Arrays.hashCode
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...29dab16b

src/hotspot/share/adlc/formssel.cpp line 911:

> 909:         strcmp(_matrule->_rChild->_opType,"CountPositives")==0 ||
> 910:         strcmp(_matrule->_rChild->_opType,"EncodeISOArray")==0)) {
> 911:         // String.(compareTo/equals/indexOf/hashCode) and Arrays.equals

Suggestion:

        // String.(compareTo/equals/indexOf/hashCode) and Arrays.(equals/hashCode)

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

PR: https://git.openjdk.java.net/jdk/pull/7700

From jrose at openjdk.java.net  Wed May 11 07:16:49 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 11 May 2022 07:16:49 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v12]
In-Reply-To: <PP7oByBGJce2DZZTe_1W4dtmld2cYUyBj-MiJEo0E58=.904b7b82-0333-4520-918b-0314f0e8fa3a@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
 <PP7oByBGJce2DZZTe_1W4dtmld2cYUyBj-MiJEo0E58=.904b7b82-0333-4520-918b-0314f0e8fa3a@github.com>
Message-ID: <LaeHYq2bt-B64RHNKHHnmLPmPv2Tu4iO-nttI4o61hY=.83244e77-bb95-44a5-b8b8-f5905777f26e@github.com>

On Tue, 10 May 2022 14:46:56 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
>> 
>> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
>> 
>> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
>> 
>> 
>> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
>> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
>> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
>> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
>> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
>> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
>> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
>> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
>> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
>> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
>> 
>> 
>> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
>> 
>> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf
>
> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Fix overlapping registers
>  - Actually fix h when hashcode is vectorized
>  - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
>  - Fix h when vectorized for Arrays.hashCode
>  - Add missing check for AryHashCode node
>  - Fix some merge conflicts
>  - Disable Arrays.hashCode intrinsic by default for CI
>  - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
>  - Some small refactoring: store power_of_31_backwards in the code directly, compact code, and more
>  - {wip} Generalize string hashcode to Arrays.hashCode
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...29dab16b

I will say, for the record, although It looks like Richard Startin scooped me by half a year (for which, kudos!), that an explicitly vectorized algorithm was independently derived as a seed challenge for the Panama Vector API.  I coded the explicitly vectorized Horner's rule loops seen in http://cr.openjdk.java.net/~jrose/vectors/vloop0.cpp in mid-2015, when we first thought there was an opportunity to do something with vector units and Java.  (Thank you Intel for believing in this crazy idea!)

I'm glad to see the current work moving forward.  I agree that an intrinsic form, rather than a magically hand-crafted Java loop, is the right way to give the JVM its call to action.

I wish we could generalize this to other instances of vectorized polynomial evaluators, rather than simply the wretchedly hardwired radix-31 one that so much of Java relies on.  Maybe we will eventually...

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

PR: https://git.openjdk.java.net/jdk/pull/7700

From asotona at openjdk.java.net  Wed May 11 07:45:39 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 07:45:39 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

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

  8244681: Add a warning for possibly lossy conversion in compound assignments
  recommended correction of the warning description

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/6b3942b8..f0729396

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

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From uschindler at openjdk.java.net  Wed May 11 07:56:37 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 11 May 2022 07:56:37 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: <kkzrEr20m9vKEr8sHN6VH_CAhHbCliUIBTr2zne8beA=.16399796-cb81-4887-82fd-72382af06feb@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <s-QyGkoKSvHjirrxqsW1AFBXqmxX_MZw-qZmU8rMi-M=.58872449-58e1-4fc4-9d1a-a5e953ec9b84@github.com>
 <kkzrEr20m9vKEr8sHN6VH_CAhHbCliUIBTr2zne8beA=.16399796-cb81-4887-82fd-72382af06feb@github.com>
Message-ID: <H0jY_gi9wMsDTKtgIDEpHStyQH1cBIYMOrwxxGxbMgM=.20d679a3-7194-4069-a761-0ef46b67b1bf@github.com>

On Tue, 10 May 2022 17:43:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/TimeZone.java line 543:
>> 
>>> 541:             return new ZoneInfo(totalSecs == 0 ? "UTC" : GMT_ID + tzid, totalSecs);
>>> 542:         } else {
>>> 543:             return getTimeZone(tzid, true);
>> 
>> Before the change in this PR, we used to prefix `GMT` to (non-custom timezone ids) if the timezone id returned by `ZoneId#getId()` started with the `+` or `-` sign, before calling `getTimeZone(modifiedTzid, true)`. 
>> With this change, for `ZoneId`s that aren't `ZoneOffset` instance, we now call `getTimeZone(originalTzid, true)`, without first checking/prefixing the id with `GMT`. Is that an intentional change and would that potentially cause `getTimeZone(String, boolean)` to return a different result?
>
> Yes, it is intentional. The `Time-zone IDs` section in the `ZoneId` class description is clear that zone id starting with "+/-" is a `ZoneOffset` instance. Other ZoneIds should have offsets with prefix or region-based ids.

I was stumbling on this, too, but it is only ZoneOffset isntances that have those strange names without GMT/UTC prefix. Default ZoneId instances created from text strings always have a prefix. If you call ZoneId.of() with an offset only and no prefix it returns a ZoneOffset instance (see the test).

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

PR: https://git.openjdk.java.net/jdk/pull/8606

From asotona at openjdk.java.net  Wed May 11 08:06:39 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 08:06:39 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v2]
In-Reply-To: <YNg7_xSMNKVRomOPRtRyyPsWSSu4Rdv28n0XOW_6xfs=.e550ad3b-66b9-417a-bff4-9ef57da7997b@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <YNg7_xSMNKVRomOPRtRyyPsWSSu4Rdv28n0XOW_6xfs=.e550ad3b-66b9-417a-bff4-9ef57da7997b@github.com>
Message-ID: <rK40I9ndXoo7IaC7c3WnDFboRAkIjuSRI9nT-fmkSYc=.6ee6adba-88cd-413b-a25e-a9e6a6dd454f@github.com>

On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove stray file

I can confirm this patch clears all warnings from java.base.

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

PR: https://git.openjdk.java.net/jdk/pull/8642

From scolebourne at openjdk.java.net  Wed May 11 08:16:40 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 11 May 2022 08:16:40 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: <RfUh38_pnxkBdxx4cK-arebwVhHR1uis66X-RY6qQNE=.db1ef511-da45-4a12-8b51-7e9dae583ee1@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <ABcvJDzCIRi4XaSaASXbB8fxcJXuyIODjxGO5J9oh0E=.7c7c2beb-bd96-4982-99e0-e19e5d4b2979@github.com>
 <RfUh38_pnxkBdxx4cK-arebwVhHR1uis66X-RY6qQNE=.db1ef511-da45-4a12-8b51-7e9dae583ee1@github.com>
Message-ID: <mfZeLSSl_CD21dZhIz4YDlVFOk7Nz5UOR4XRhF9yOUc=.a2319b8c-cd28-4df1-bddb-121e85ecc6a1@github.com>

On Tue, 10 May 2022 17:43:07 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/util/TimeZone/ZoneOffsetRoundTripTest.java line 43:
>> 
>>> 41:     private Object[][] testZoneOffsets() {
>>> 42:         return new Object[][] {
>>> 43:                 {ZoneId.of("Z"), 0},
>> 
>> I know, `ZoneId.of()` should parse this as a `ZoneOffset` and return a `ZoneOffset` instance, but maybe add also the other string variants with prefix (`ZoneId.of("UTC+00:00:01")` or `ZoneId.of("GMT+00:00:01")` as data items. Maybe also use `ZoneOffset.of()` for the plain zones to be explicit.
>
> Added them except "UTC+...", as it is not recognizable as a Custom ID.

Can the test cover `UT` prefix as well? (This is another valid prefix in `ZoneId`)

If this PR isn't meant to work with UTC prefix, can a test be added that proves it does *not* work.

ie. all these are valid in `ZoneId` - "Z", "UTC", "GMT", "UT", "UTC+01:00", "GMT+01:00", "UT+01:00" - and all should have some form of associated test.

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

PR: https://git.openjdk.java.net/jdk/pull/8606

From uschindler at openjdk.java.net  Wed May 11 08:36:35 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 11 May 2022 08:36:35 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: <mfZeLSSl_CD21dZhIz4YDlVFOk7Nz5UOR4XRhF9yOUc=.a2319b8c-cd28-4df1-bddb-121e85ecc6a1@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <ABcvJDzCIRi4XaSaASXbB8fxcJXuyIODjxGO5J9oh0E=.7c7c2beb-bd96-4982-99e0-e19e5d4b2979@github.com>
 <RfUh38_pnxkBdxx4cK-arebwVhHR1uis66X-RY6qQNE=.db1ef511-da45-4a12-8b51-7e9dae583ee1@github.com>
 <mfZeLSSl_CD21dZhIz4YDlVFOk7Nz5UOR4XRhF9yOUc=.a2319b8c-cd28-4df1-bddb-121e85ecc6a1@github.com>
Message-ID: <0w73_YddkD3sWCUqC6EsEue-oOCZyxvPqWJA2QSZgCY=.8700718e-64b2-4781-8e54-f5e5a838291d@github.com>

On Wed, 11 May 2022 08:10:56 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Added them except "UTC+...", as it is not recognizable as a Custom ID.
>
> Can the test cover `UT` prefix as well? (This is another valid prefix in `ZoneId`)
> 
> If this PR isn't meant to work with UTC prefix, can a test be added that proves it does *not* work.
> 
> ie. all these are valid in `ZoneId` - "Z", "UTC", "GMT", "UT", "UTC+01:00", "GMT+01:00", "UT+01:00" - and all should have some form of associated test.

I tried it out: If you create a ZoneId with prefixes "UT" and "UTC", they fail to convert to TimeZone. Same happens if you use this as String name in `TimeZone#getTimeZone(String)`. This is another bug / missing feature! It does not work with or without this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8606

From ysuenaga at openjdk.java.net  Wed May 11 08:40:21 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 11 May 2022 08:40:21 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
Message-ID: <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
> 
> * -Wstringop-overflow
>     * src/hotspot/share/oops/array.hpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
> 
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

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

  Avoid pragma error in before GCC 12

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8646/files
  - new: https://git.openjdk.java.net/jdk/pull/8646/files/8154f6ea..7f155256

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

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646

PR: https://git.openjdk.java.net/jdk/pull/8646

From shade at openjdk.java.net  Wed May 11 08:55:46 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 11 May 2022 08:55:46 GMT
Subject: RFR: 8286473: Drop --enable-preview from Record related tests [v2]
In-Reply-To: <N50hBys42VgQvYc5wQbCUqhHC0gQxGZREXWGrx6I7fk=.f9b83ace-b449-4dda-b2b1-db0cfaf43c08@github.com>
References: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
 <N50hBys42VgQvYc5wQbCUqhHC0gQxGZREXWGrx6I7fk=.f9b83ace-b449-4dda-b2b1-db0cfaf43c08@github.com>
Message-ID: <0We5XaRjaSzPrgkyx6CIQwDrxDuNMQZdrT3BSdAHhpk=.2fe2351c-68ee-4bca-a980-4e563b2a6b6e@github.com>

On Tue, 10 May 2022 14:54:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, affected tests still pass
>>  - [x]  Linux x86_32 fastdebug, affected tests start to pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thanks for reviews. I see GHA are mostly clean, with the usual x86_32 failures.

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

PR: https://git.openjdk.java.net/jdk/pull/8626

From shade at openjdk.java.net  Wed May 11 08:55:47 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 11 May 2022 08:55:47 GMT
Subject: Integrated: 8286473: Drop --enable-preview from Record related tests
In-Reply-To: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
References: <nma8QeUWTtwi_IGHBvoZSPrzOXhqFl6KFu-j1D9Kj50=.31081010-1ba5-45c4-87cf-02b2317d26a3@github.com>
Message-ID: <u90BnU7Un8yVj--CB864hsRAat4-g8JigPjRQMkEsGU=.26468f83-a7de-41f7-b285-89d5820a9c72@github.com>

On Tue, 10 May 2022 12:03:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are plenty of tests failing on many architectures due to `--enable-preview` VM code introduced by Loom. This improvements eliminates some of the redundant `--enable-preview` clauses from the Record tests, since Records have been graduated from preview in JDK 16. 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, affected tests still pass
>  - [x]  Linux x86_32 fastdebug, affected tests start to pass

This pull request has now been integrated.

Changeset: 73c5e993
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/73c5e993e17f7435553edae79a1e8d70ece5493d
Stats:     30 lines in 3 files changed: 0 ins; 24 del; 6 mod

8286473: Drop --enable-preview from Record related tests

Reviewed-by: alanb, jpai, mchung

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

PR: https://git.openjdk.java.net/jdk/pull/8626

From uschindler at openjdk.java.net  Wed May 11 09:04:46 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 11 May 2022 09:04:46 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: <0w73_YddkD3sWCUqC6EsEue-oOCZyxvPqWJA2QSZgCY=.8700718e-64b2-4781-8e54-f5e5a838291d@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <ABcvJDzCIRi4XaSaASXbB8fxcJXuyIODjxGO5J9oh0E=.7c7c2beb-bd96-4982-99e0-e19e5d4b2979@github.com>
 <RfUh38_pnxkBdxx4cK-arebwVhHR1uis66X-RY6qQNE=.db1ef511-da45-4a12-8b51-7e9dae583ee1@github.com>
 <mfZeLSSl_CD21dZhIz4YDlVFOk7Nz5UOR4XRhF9yOUc=.a2319b8c-cd28-4df1-bddb-121e85ecc6a1@github.com>
 <0w73_YddkD3sWCUqC6EsEue-oOCZyxvPqWJA2QSZgCY=.8700718e-64b2-4781-8e54-f5e5a838291d@github.com>
Message-ID: <wluLyGYv6WoSD95I3xa0n-F0KX7NUo63BxuaHaMH7sg=.bad6f2bb-5d6d-4ae3-8d21-5c50aa32146a@github.com>

On Wed, 11 May 2022 08:32:48 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> Can the test cover `UT` prefix as well? (This is another valid prefix in `ZoneId`)
>> 
>> If this PR isn't meant to work with UTC prefix, can a test be added that proves it does *not* work.
>> 
>> ie. all these are valid in `ZoneId` - "Z", "UTC", "GMT", "UT", "UTC+01:00", "GMT+01:00", "UT+01:00" - and all should have some form of associated test.
>
> I tried it out: If you create a ZoneId with prefixes "UT" and "UTC", they fail to convert to TimeZone. Same happens if you use this as String name in `TimeZone#getTimeZone(String)`. This is another bug / missing feature! It does not work with or without this PR.

In short, we can only test what works. The test was mainly added to allow roundtrips of `ZoneOffset` instances.

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

PR: https://git.openjdk.java.net/jdk/pull/8606

From jpai at openjdk.java.net  Wed May 11 09:09:16 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 11 May 2022 09:09:16 GMT
Subject: RFR: 8286559: Re-examine synchronization of mark and reset methods on
 InflaterInputStream
Message-ID: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>

Can I please get a review of this change that addresses https://bugs.openjdk.java.net/browse/JDK-8286559? 

The commit here removes the `synchronized` on `mark` and `reset` methods of `InflaterInputStream`. The `mark` method is a no-op method and the `reset` method only always throws a `IOException`. So `synchronized` isn't adding any value here. 

Additionally, the commit does a minor change to the javadoc of these methods to use `@implNote` to describe what the implementation does. Please let me know if the `@implNote` is unnecessary, in which case, I'll revert that part.

This change is similar to what was recently done for `FilterInputStream` https://github.com/openjdk/jdk/pull/8309 and `PushbackInputStream` https://github.com/openjdk/jdk/pull/8433

tier1, tier2 and tier3 tests were run and no related failures were noticed.

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

Commit messages:
 - 8286559: Re-examine synchronization of mark and reset methods on InflaterInputStream

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

PR: https://git.openjdk.java.net/jdk/pull/8649

From duke at openjdk.java.net  Wed May 11 09:09:49 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 11 May 2022 09:09:49 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v11]
In-Reply-To: <UkougCywkC6YSJeQRa0G5TCY6H8xZheWyGpZwLUCyqM=.6b53d8f9-b0f8-470b-bfec-368056d706bf@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <kTriMC8iN5G6dEKD3Pkr3KDynWu4AHR6WZ5FuLHTjVo=.eee31814-43c3-4e20-b373-36f5bc078426@github.com>
 <UkougCywkC6YSJeQRa0G5TCY6H8xZheWyGpZwLUCyqM=.6b53d8f9-b0f8-470b-bfec-368056d706bf@github.com>
Message-ID: <IIMQABT9uPdmBx-Y8kHrWgIIyboDsPUKIcGRzJlhNCc=.ff66365b-2d32-4da2-9d4a-bb1c540c76fd@github.com>

On Tue, 10 May 2022 03:22:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   4511638: Double.toString(double) sometimes produces incorrect results
>
> src/java.base/share/classes/java/lang/Double.java line 33:
> 
>> 31: import java.util.Optional;
>> 32: 
>> 33: import jdk.internal.math.FloatingDecimal;
> 
> Presumably the FloatingDecimal import here and in Float can be removed.

`FloatingDecimal` is used in the `parse*(String)` methods

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

PR: https://git.openjdk.java.net/jdk/pull/3402

From xgong at openjdk.java.net  Wed May 11 09:33:45 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 11 May 2022 09:33:45 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store
In-Reply-To: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
Message-ID: <DPTG8IrVd3uNjZQ92srZXN3ezUrvBzIisEg_cQvIzwM=.5f5d5d3a-d2fc-4426-98f0-3db767bd697a@github.com>

On Tue, 10 May 2022 01:23:55 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
> 
> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
> 
> Benchmark                                   Before    After     Gain Units
> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
> 
> Similar performane gain can also be observed on ARM hardware.

Hi @PaulSandoz @rose00, could you please help to take a look at this simple PR? Thanks so much!

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

PR: https://git.openjdk.java.net/jdk/pull/8620

From lancea at openjdk.java.net  Wed May 11 10:09:46 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 11 May 2022 10:09:46 GMT
Subject: RFR: 8286559: Re-examine synchronization of mark and reset methods
 on InflaterInputStream
In-Reply-To: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
References: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
Message-ID: <hcmEX6O5c--zfU7xlmQymAZvvd3nDeRYavtoE31heYE=.da6676ee-4366-4b84-9f85-ef89e0bb2009@github.com>

On Wed, 11 May 2022 09:00:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change that addresses https://bugs.openjdk.java.net/browse/JDK-8286559? 
> 
> The commit here removes the `synchronized` on `mark` and `reset` methods of `InflaterInputStream`. The `mark` method is a no-op method and the `reset` method only always throws a `IOException`. So `synchronized` isn't adding any value here. 
> 
> Additionally, the commit does a minor change to the javadoc of these methods to use `@implNote` to describe what the implementation does. Please let me know if the `@implNote` is unnecessary, in which case, I'll revert that part.
> 
> This change is similar to what was recently done for `FilterInputStream` https://github.com/openjdk/jdk/pull/8309 and `PushbackInputStream` https://github.com/openjdk/jdk/pull/8433
> 
> tier1, tier2 and tier3 tests were run and no related failures were noticed.

Hi Jai,

I am fine with the change.  It will also need a  CSR

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8649

From jpai at openjdk.java.net  Wed May 11 10:23:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 11 May 2022 10:23:40 GMT
Subject: RFR: 8286559: Re-examine synchronization of mark and reset methods
 on InflaterInputStream
In-Reply-To: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
References: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
Message-ID: <XiqX85tJgWYTEnxxRxjbbYOal-fvjwkvt6uZ-Gay_zA=.61bc7594-b284-4988-b85d-e8dcd5151c13@github.com>

On Wed, 11 May 2022 09:00:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change that addresses https://bugs.openjdk.java.net/browse/JDK-8286559? 
> 
> The commit here removes the `synchronized` on `mark` and `reset` methods of `InflaterInputStream`. The `mark` method is a no-op method and the `reset` method only always throws a `IOException`. So `synchronized` isn't adding any value here. 
> 
> Additionally, the commit does a minor change to the javadoc of these methods to use `@implNote` to describe what the implementation does. Please let me know if the `@implNote` is unnecessary, in which case, I'll revert that part.
> 
> This change is similar to what was recently done for `FilterInputStream` https://github.com/openjdk/jdk/pull/8309 and `PushbackInputStream` https://github.com/openjdk/jdk/pull/8433
> 
> tier1, tier2 and tier3 tests were run and no related failures were noticed.

Hello Lance, thank you for the review. I have created a CSR for this now - https://bugs.openjdk.java.net/browse/JDK-8286579

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

PR: https://git.openjdk.java.net/jdk/pull/8649

From duke at openjdk.java.net  Wed May 11 10:34:45 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 11 May 2022 10:34:45 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v12]
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <taXgdIaBigTGc-7vfFWEGKbpDokB38pCBP7Teqjw0m8=.726577f1-0f0c-4076-8c82-8fe129f7d1fa@github.com>

> Hello,
> 
> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
> 
> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
> 
> 
> Greetings
> Raffaello

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

  4511638: Double.toString(double) sometimes produces incorrect results

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3402/files
  - new: https://git.openjdk.java.net/jdk/pull/3402/files/907abfd6..b40d7e80

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=10-11

  Stats: 28 lines in 7 files changed: 0 ins; 9 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402

PR: https://git.openjdk.java.net/jdk/pull/3402

From mcimadamore at openjdk.java.net  Wed May 11 10:39:44 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 11 May 2022 10:39:44 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v44]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <nYEfBb0y4TtQ3webD87xAB7Hdwwdb1n0sY6Ff2Mfl0U=.e640ddd8-bee5-4a91-9277-06ac0ccf0993@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:

 - Merge branch 'master' into foreign-preview
 - Fix crashes in heap segment benchmarks due to misaligned access
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Add tests for loaderLookup/restricted method corner cases
 - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
   * Tweak restricted method check to work when there's no caller class
 - Tweak examples in SymbolLookup javadoc
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Tweak support for Linker lookup
   Improve javadoc of SymbolLookup
 - ... and 54 more: https://git.openjdk.java.net/jdk/compare/73c5e993...cdd006e7

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

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=43
  Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From jvernee at openjdk.java.net  Wed May 11 10:45:12 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 10:45:12 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <LrXnPwnYURipSTuL3AGudgEUAp7FbchsgVHYr20hcrE=.533d8088-f6d5-4a2b-aea0-81fc75d7522e@github.com>

On Tue, 10 May 2022 18:44:01 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/cpu/aarch64/frame_aarch64.cpp line 379:
> 
>> 377:   // need unextended_sp here, since normal sp is wrong for interpreter callees
>> 378:   return reinterpret_cast<OptimizedEntryBlob::FrameData*>(
>> 379:     reinterpret_cast<char*>(frame.unextended_sp()) + in_bytes(_frame_data_offset));
> 
> Maybe use `address` instead of `char*`?

Ok. I think I used `char*` to try and avoid a potential strict-aliasing violation, but I don't think we compile with that turned on any ways.

Will change it to `address` (for x86 too)

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 10:50:47 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 10:50:47 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <U_p9jYzrJ9cXRrtc_erghi58eTNS2e8-LCl8FF15SCw=.3a81fdcc-00f4-4126-ab2e-0cf0f96c3858@github.com>

On Tue, 10 May 2022 18:48:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5547:
> 
>> 5545:   } else if (dst.first()->is_stack()) {
>> 5546:     // reg to stack
>> 5547:     // Do we really have to sign extend???
> 
> Obsolete? Remove?

Yes, this looks like it can be removed. (was copied over from SharedRuntime_aarch64)

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 10:55:09 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 10:55:09 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <l7Tl9sW0p-wgSmJTrnqi7anuU-bOJFqybfe-loihapU=.7a94ee0b-55c4-44c7-ab69-4d02a9c3bdd6@github.com>

On Tue, 10 May 2022 18:55:03 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30:
> 
>> 28: #include "utilities/growableArray.hpp"
>> 29: 
>> 30: class outputStream;
> 
> Redundant declaration?

Yeah, this whole file is redundant :) (replaced by foreign_globals_x86_64.hpp)

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 11:02:47 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 11:02:47 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <gYl6-EdIWfSivkxKtmEKAFEHAjvpdkQjmN7mljtycJk=.f18975e7-27e7-412e-93a8-8715d9c73596@github.com>

On Tue, 10 May 2022 19:16:35 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/share/code/codeBlob.hpp line 754:
> 
>> 752: class ProgrammableUpcallHandler;
>> 753: 
>> 754: class OptimizedEntryBlob: public RuntimeBlob {
> 
> What's the motivation to move `OptimizedEntryBlob` up in the hierarchy (from `BufferBlob` to `RuntimeBlob`)?

Some of it is discussed here: https://github.com/openjdk/panama-foreign/pull/617

Essentially, it is to avoid accidentally inheriting behavior from BufferBlob which we don't want. Also, BufferBlob currently expects a fixed-sized header (`sizeof(BufferBlob)`), while OptimizedEntryBlobs has fields, so we'd have to pass the real header size to the `BufferBlob` constructor, which is a bit messy.

It felt better to just cleanly break away from BufferBlob.

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 11:09:52 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 11:09:52 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <zCv3AQoTrDLchF5553FpJDjwvDx8KGuCbWOEDU6ezT0=.3a5cfd8f-ac88-43a5-a3f8-65248154a777@github.com>

On Tue, 10 May 2022 19:21:58 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/share/opto/callGenerator.cpp line 1131:
> 
>> 1129: 
>> 1130:     case vmIntrinsics::_linkToNative:
>> 1131:     print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(),
> 
> Why is it unconditionally reported as inlining failure?

The call that is being processed here is `linkToNative`, and that call is not inlined, so reporting an inlining failure seems correct. We still go through the method handle trampoline stub which loads the actual target from the NativeEntryPoint (`jump_to_native_invoker` in methodHandles_x86.cpp).

It's potentially faster here to generate a runtime call to the underlying invoker/downcall stub if the NativeEntryPoint is constant (i.e. avoid the lookup through NEP in the MH trampoline), but I hadn't gotten to investigating that yet.

>From comparing the benchmark times between this and the old implementation (which generated an inline call), they are not all that different. So it seemed that doing something special here would not save that much time any ways. (but, still would be good to investigate at some point)

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 11:13:53 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 11:13:53 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <GjSoNU6wytvMhj8X_rPNajx9CMalQB3LD1kk82yUpuM=.0f10f14a-3198-4a89-93a5-2396b08b16cd@github.com>

On Tue, 10 May 2022 20:30:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/share/prims/foreign_globals.cpp line 147:
> 
>> 145: // based on ComputeMoveOrder from x86_64 shared runtime code.
>> 146: // with some changes.
>> 147: class ForeignCMO: public StackObj {
> 
> Considering how seldom it is used, I don't see much value in abbreviating it. Also, the comment is misleading: there's no such entity as `ComputeMoveOrder` in the code. And `compute_move_order` is completely removed by this change.

Good points, I think we can just rename this class to `ComputeMoveOrder` at this point.

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jpai at openjdk.java.net  Wed May 11 11:18:37 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 11 May 2022 11:18:37 GMT
Subject: RFR: 8286287: Reading file as UTF-16 causes Error which
 "shouldn't happen"
In-Reply-To: <oCWtLqDR1Wh8DCeIeCdLExXp9JXEPZ2LMODfe0FDaZs=.03d127d4-316d-4be0-96fc-fbfe61031dd4@github.com>
References: <oCWtLqDR1Wh8DCeIeCdLExXp9JXEPZ2LMODfe0FDaZs=.03d127d4-316d-4be0-96fc-fbfe61031dd4@github.com>
Message-ID: <XJ2q4C_m6J1Zqcw3XsBpY5om3gC4FLeGgVYu7PjSut8=.7c73f525-8bd6-41d7-b24b-14e51a0d6daf@github.com>

On Tue, 10 May 2022 20:22:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter replaces on malformed/unmappable characters with replacements. However, there was a code path that lacked to set the `CodingErrorAction.REPLACE` on the decoder. Unrelated, one typo in a test was also fixed.

Marked as reviewed by jpai (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/8640

From jvernee at openjdk.java.net  Wed May 11 11:28:05 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 11:28:05 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <wkO5beq7onxaGRl1VNoIIykmk--4kFw-DRDykzPgo78=.7de91799-5f22-4791-a28b-88f993041b9c@github.com>

On Tue, 10 May 2022 20:48:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/share/prims/foreign_globals.hpp line 35:
> 
>> 33: #include CPU_HEADER(foreign_globals)
>> 34: 
>> 35: class CallConvClosure {
> 
> Just a question on terminology: why is it called a `Closure`?

It is the terminology used in other parts of hotspot for function objects it seems. See for instance the classes in `iterator.hpp`

> src/hotspot/share/prims/foreign_globals.hpp line 62:
> 
>> 60: 
>> 61: 
>> 62: class JavaCallConv : public CallConvClosure {
> 
> Does it really worth to abbreviate `CallingConvention` to `CallConv`?

Maybe not... I'll spell out the full thing.

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jpai at openjdk.java.net  Wed May 11 11:46:00 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 11 May 2022 11:46:00 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled
Message-ID: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>

Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`?

With this change the build now passes (tested both with bundled and system zlib variants).

tier1, tier2 and tier3 testing has been done and no related failures have been noticed.

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

Commit messages:
 - fix build issues with bundled zlib on macosx

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

PR: https://git.openjdk.java.net/jdk/pull/8651

From ihse at openjdk.java.net  Wed May 11 11:50:50 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 11:50:50 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
Message-ID: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com>

On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid pragma error in before GCC 12

The harfbuzz disabled warning looks good, so build changes are approved. You'll still need approval for the rest of the changes.

While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it...

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8646

From ihse at openjdk.java.net  Wed May 11 11:59:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 11:59:43 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled
In-Reply-To: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
Message-ID: <SqjQt4L5AItmvC7ZzS7fXjsv0Fi7bzlYpn4KLp-eALc=.42365450-36e2-44d4-858a-5387864eb47d@github.com>

On Wed, 11 May 2022 11:38:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`?
> 
> With this change the build now passes (tested both with bundled and system zlib variants).
> 
> tier1, tier2 and tier3 testing has been done and no related failures have been noticed.

Changes requested by ihse (Reviewer).

make/autoconf/lib-bundled.m4 line 224:

> 222:   LIBZ_LIBS=""
> 223:   if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then
> 224:     LIBZ_CFLAGS="$LIBZ_CFLAGS $APPLE_LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib"

Declaring APPLE_LIBZ_CFLAGS far away (and only conditionally) and then using it once here just makes for hard-to-read code. 

Suggestion:

    LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib"
    if test "x$OPENJDK_TARGET_OS" = xmacosx; then
      LIBZ_CFLAGS="$LIBZ_CFLAGS -DHAVE_UNISTD_H"
    fi

... and remove the assignment above.

src/java.base/share/native/libzip/zlib/gzwrite.c line 452:

> 450:     len = strlen(next);
> 451: #  else
> 452: #   ifdef __APPLE__ // ignore format-nonliteral warning on macOS

Instead of patching 3rd party code to fix a compilation warning, you should disable that warning instead.

In `make/modules/java.base/lib/CoreLibraries.gmk`, add 

DISABLED_WARNINGS_clang := format-nonliteral, \

as line 138.

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

PR: https://git.openjdk.java.net/jdk/pull/8651

From jvernee at openjdk.java.net  Wed May 11 12:08:53 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 12:08:53 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>

On Tue, 10 May 2022 21:01:48 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306:
> 
>> 304:   intptr_t exception_handler_offset = __ pc() - start;
>> 305: 
>> 306:   // Native caller has no idea how to handle exceptions,
> 
> Can you elaborate, please, how it is expected to work in presence of asynchronous exceptions? I'd expect to see a code which unconditionally clears pending exception with an assertion that verifies that the exception is of expected type.

We have an exception handler in Java as well, so this code is only a fail safe. But, I think in the case of asynchronous exceptions this might be problematic if the exception is discovered by the current thread outside of the Java exception handler, turned into a synchronous exception and then we get here and call `ProgrammableUpcallhandler::handle_uncaught_exception` and then crash. Or if the asynchronous exception is discovered in `ProgrammableUpcallHandler::on_exit` (where there is currently an assert for no exceptions).

I think you're right that, in both of those cases, if the exception is asynchronous, we should just ignore it.

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 12:19:05 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 12:19:05 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <l7Tl9sW0p-wgSmJTrnqi7anuU-bOJFqybfe-loihapU=.7a94ee0b-55c4-44c7-ab69-4d02a9c3bdd6@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <l7Tl9sW0p-wgSmJTrnqi7anuU-bOJFqybfe-loihapU=.7a94ee0b-55c4-44c7-ab69-4d02a9c3bdd6@github.com>
Message-ID: <fZJx50l9Mi57YJmXHwW8pw5jCPccSC-y8Ox1mvxLOo8=.5e37a761-b284-4806-bc82-9ee28943ab71@github.com>

On Wed, 11 May 2022 10:51:10 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30:
>> 
>>> 28: #include "utilities/growableArray.hpp"
>>> 29: 
>>> 30: class outputStream;
>> 
>> Redundant declaration?
>
> Yeah, this whole file is redundant :) (replaced by foreign_globals_x86_64.hpp)

Hmm, it doesn't look like having x64 specific header files is support by the CPU_HEADER macros. Will stick to the shared header file for x86_32 and x86_64 for now.

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 12:23:59 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 12:23:59 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <PZA8rAeJCZ6s7rrMr1TJlYGp7DuOn6QHyPCxMsaHCqk=.dea02a2e-aa4a-4318-a2e7-116065395826@github.com>

On Tue, 10 May 2022 20:45:02 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/cpu/x86/foreign_globals_x86_64.cpp line 52:
> 
>> 50: 
>> 51:   objArrayOop inputStorage = jdk_internal_foreign_abi_ABIDescriptor::inputStorage(abi_oop);
>> 52:   loadArray(inputStorage, INTEGER_TYPE, abi._integer_argument_registers, as_Register);
> 
> `loadArray` helper looks a bit misleading. In presence of `javaClass`-style accessors, it misleadingly hints that it refers to some Java-level operation/entity, though what it does it parses register list representation backed by a Java array. I suggest to rename it to something like `parse_argument_registers_array()`).

I went with `parse_register_array` (since it's also used for return registers)

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 12:24:02 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 12:24:02 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <F0kIhISiVv7a-ST9aj9bMEe7o3kXcGdYcaL8TLj6o5Y=.623c3848-179d-4dee-8ea2-61cf185a8a2d@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <SSI4EbbwAEFokP_lQ3ET9TZRNzxEC6DHZ2_hvQft3eo=.70763ae0-6260-40f7-99d5-6bd151a70ee4@github.com>
 <F0kIhISiVv7a-ST9aj9bMEe7o3kXcGdYcaL8TLj6o5Y=.623c3848-179d-4dee-8ea2-61cf185a8a2d@github.com>
Message-ID: <kQkdmddPF36nfoOCR4zkE-uKuHQByHkXxfdz0xdoaBc=.eeb14892-9d42-4ac1-854e-58b9401290d0@github.com>

On Tue, 10 May 2022 20:53:37 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/utilities/growableArray.hpp line 151:
>> 
>>> 149:     return _data;
>>> 150:   }
>>> 151: 
>> 
>> This accessor is added to be able to temporarily view a stable GrowableArray instance as a C-style array. It is used to by `NativeCallConv` and `RegSpiller` in `foreign_globals.hpp`.
>> 
>> GrowableArray already has an `adr_at` accessor that does something similar, but using `adr_at(0)` fails on empty growable arrays since it also performs a bounds check. So it can not be used.
>
> Any problems with migrating `CallConv` and `RegSpiller`away from ` VMReg* + int` to `GrowableArray<VMReg>`?

I'll try migrating to `GrowableArray`

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From ysuenaga at openjdk.java.net  Wed May 11 12:38:58 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 11 May 2022 12:38:58 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
 <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com>
Message-ID: <acrQQd7p33cmxO37jmKWvhB2cOfp8LplFHsueYhoyV8=.e72e3acb-9cdb-4ec4-b2cb-ec68e4480a3f@github.com>

On Wed, 11 May 2022 11:48:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid pragma error in before GCC 12
>
> The harfbuzz disabled warning looks good, so build changes are approved. You'll still need approval for the rest of the changes.
> 
> While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it...

Thanks @magicus for your review!

> While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it...

Agree, so I fixed bugs which were found out by compiler warnings in this PR - they are in libjli.
I think we can ignore the others because they are already checked in other methods (e.g. `assert`), or due to structure of `Array` class which has payload in `_data[1]` (and it is also checked in `assert`).

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

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Wed May 11 12:43:01 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 11 May 2022 12:43:01 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
Message-ID: <2NpNw3Q9tkAShuydzhDKopMf3mLCyAwmSFoWzC665pI=.dbe3b460-d267-42ab-b08d-553bf133b796@github.com>

On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid pragma error in before GCC 12

It is better to add pragma to `Array::at_put()` in src/hotspot/share/oops/array.hpp , but I couldn't suppress warnings. So I added pragmas to its caller - bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp .

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

PR: https://git.openjdk.java.net/jdk/pull/8646

From alanb at openjdk.java.net  Wed May 11 12:51:56 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 12:51:56 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
Message-ID: <xAbp-fgepaMu55vblB-DmNHD62E39JrY7sIdiPGGe7A=.e1b0b8f1-8091-44d6-a8d5-2a6f5520fb5d@github.com>

On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid pragma error in before GCC 12

src/java.base/unix/native/libjli/java_md_common.c line 135:

> 133:     if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0;
> 134:     JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd);
> 135: #pragma GCC diagnostic pop

Can we just replace this code rather than putting pragmas here?

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

PR: https://git.openjdk.java.net/jdk/pull/8646

From jpai at openjdk.java.net  Wed May 11 12:54:02 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 11 May 2022 12:54:02 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled
In-Reply-To: <SqjQt4L5AItmvC7ZzS7fXjsv0Fi7bzlYpn4KLp-eALc=.42365450-36e2-44d4-858a-5387864eb47d@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <SqjQt4L5AItmvC7ZzS7fXjsv0Fi7bzlYpn4KLp-eALc=.42365450-36e2-44d4-858a-5387864eb47d@github.com>
Message-ID: <tx7ovbOEUxPDOSQfQkZI03FrISR2fEEhn64j4xBeiuI=.c46c7063-119a-4fce-a934-3ef0bff84a7c@github.com>

On Wed, 11 May 2022 11:56:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`?
>> 
>> With this change the build now passes (tested both with bundled and system zlib variants).
>> 
>> tier1, tier2 and tier3 testing has been done and no related failures have been noticed.
>
> src/java.base/share/native/libzip/zlib/gzwrite.c line 452:
> 
>> 450:     len = strlen(next);
>> 451: #  else
>> 452: #   ifdef __APPLE__ // ignore format-nonliteral warning on macOS
> 
> Instead of patching 3rd party code to fix a compilation warning, you should disable that warning instead.
> 
> In `make/modules/java.base/lib/CoreLibraries.gmk`, add 
> 
> DISABLED_WARNINGS_clang := format-nonliteral, \
> 
> as line 138.

Thank you for these useful inputs Magnus. I did these changes locally but for some reason this format-nonliteral is not getting picked up while building that library. I will investigate and see what's going on. Will update the PR once I figure it out.

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

PR: https://git.openjdk.java.net/jdk/pull/8651

From alanb at openjdk.java.net  Wed May 11 12:54:03 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 12:54:03 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled
In-Reply-To: <tx7ovbOEUxPDOSQfQkZI03FrISR2fEEhn64j4xBeiuI=.c46c7063-119a-4fce-a934-3ef0bff84a7c@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <SqjQt4L5AItmvC7ZzS7fXjsv0Fi7bzlYpn4KLp-eALc=.42365450-36e2-44d4-858a-5387864eb47d@github.com>
 <tx7ovbOEUxPDOSQfQkZI03FrISR2fEEhn64j4xBeiuI=.c46c7063-119a-4fce-a934-3ef0bff84a7c@github.com>
Message-ID: <1VProTCyDpN_GDpPOkBynPmEjGkNhicS7ZINpTLYAdo=.654b6689-d3e1-42ca-b4d6-e0c324a3ce45@github.com>

On Wed, 11 May 2022 12:47:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/native/libzip/zlib/gzwrite.c line 452:
>> 
>>> 450:     len = strlen(next);
>>> 451: #  else
>>> 452: #   ifdef __APPLE__ // ignore format-nonliteral warning on macOS
>> 
>> Instead of patching 3rd party code to fix a compilation warning, you should disable that warning instead.
>> 
>> In `make/modules/java.base/lib/CoreLibraries.gmk`, add 
>> 
>> DISABLED_WARNINGS_clang := format-nonliteral, \
>> 
>> as line 138.
>
> Thank you for these useful inputs Magnus. I did these changes locally but for some reason this format-nonliteral is not getting picked up while building that library. I will investigate and see what's going on. Will update the PR once I figure it out.

I agree with Magnus and try to avoid changing the imported zlib code.

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

PR: https://git.openjdk.java.net/jdk/pull/8651

From sgehwolf at openjdk.java.net  Wed May 11 13:02:50 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 11 May 2022 13:02:50 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
Message-ID: <FcSYaD_FPWZedPFvI0tGxBiQyoAsDoRU1_f9S-xiDAI=.d98d4c7b-fe87-4c79-94cb-e36bd06b7810@github.com>

On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values).
> 
> No test regressions observed in jdk/com/sun/jndi/ldap.
> 
> --
> [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137

please don't auto-close this bot.

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

PR: https://git.openjdk.java.net/jdk/pull/6043

From ihse at openjdk.java.net  Wed May 11 13:05:46 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 13:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
Message-ID: <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>

On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8244681: Add a warning for possibly lossy conversion in compound assignments
>   recommended correction of the warning description

Check updates on JDK-8286374 subtasks.

make/modules/jdk.jfr/Java.gmk line 26:

> 24: #
> 25: 
> 26: DISABLED_WARNINGS_java += exports lossy-conversions

Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 

In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.

(In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)

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

Changes requested by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Wed May 11 13:05:46 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 13:05:46 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
Message-ID: <PWtwdccbXVxNM6h8D5nH5AzTqjGk9y5se7lGEE-ToHU=.135fd8e6-f702-41c0-9397-e165c29adb77@github.com>

On Wed, 11 May 2022 07:45:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
>> 
>> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
>> 
>> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
>> 
>> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
>> 
>> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
>> 
>> Thanks for your review,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8244681: Add a warning for possibly lossy conversion in compound assignments
>   recommended correction of the warning description

Lossy conversion issues for jdk.jfr and jdk.management.jfr. have been fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From egahlin at openjdk.java.net  Wed May 11 13:08:49 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 11 May 2022 13:08:49 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
Message-ID: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>

On Wed, 11 May 2022 12:59:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8244681: Add a warning for possibly lossy conversion in compound assignments
>>   recommended correction of the warning description
>
> make/modules/jdk.jfr/Java.gmk line 26:
> 
>> 24: #
>> 25: 
>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
> 
> Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 
> 
> In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.
> 
> (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)

I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From ihse at openjdk.java.net  Wed May 11 13:13:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 13:13:43 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
Message-ID: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>

On Wed, 11 May 2022 13:05:45 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> make/modules/jdk.jfr/Java.gmk line 26:
>> 
>>> 24: #
>>> 25: 
>>> 26: DISABLED_WARNINGS_java += exports lossy-conversions
>> 
>> Note that with the fix of JDK-8286392 (and JDK-8286396) the `lossy-conversions` warning should not be disabled for the JFR code. 
>> 
>> In general, you need to check which of the subtasks of JDK-8286374 that has been fixed, and adjust the makefiles accordingly, before pushing this fix.
>> 
>> (In the future, it might be easier to push the fix which disables the warnings first, and then file follow-up bugs on aa per-component basis, and remind them to remove the disabling in the makefile. That way there won't be a race between individual fixes and a "master" bug like this.)
>
> I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.

That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From ysuenaga at openjdk.java.net  Wed May 11 13:24:38 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 11 May 2022 13:24:38 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <xAbp-fgepaMu55vblB-DmNHD62E39JrY7sIdiPGGe7A=.e1b0b8f1-8091-44d6-a8d5-2a6f5520fb5d@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
 <xAbp-fgepaMu55vblB-DmNHD62E39JrY7sIdiPGGe7A=.e1b0b8f1-8091-44d6-a8d5-2a6f5520fb5d@github.com>
Message-ID: <Pkjh4Y2i5glq2BPrYAURCuJ6gvJB9dUl7GMGmTKMQYY=.5016182f-28da-447a-9a96-212361c94257@github.com>

On Wed, 11 May 2022 12:48:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid pragma error in before GCC 12
>
> src/java.base/unix/native/libjli/java_md_common.c line 135:
> 
>> 133:     if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0;
>> 134:     JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd);
>> 135: #pragma GCC diagnostic pop
> 
> Can we just replace this code rather than putting pragmas here?

I tried several patterns, but I couldn't find out a solution other than pragmas. Do you have any ideas?

For example:

    if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) < sizeof(name)) {
      JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd);
    } else {
      return 0;
    }


Compiler warnings:

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

PR: https://git.openjdk.java.net/jdk/pull/8646

From asotona at openjdk.java.net  Wed May 11 13:30:43 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:30:43 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
Message-ID: <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>

On Wed, 11 May 2022 13:10:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I agree, but if it doesn't happen, I can follow up with a separate PR where I remove the disablement.
>
> That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.

Thanks for quick reaction.
I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From rriggs at openjdk.java.net  Wed May 11 13:34:49 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 13:34:49 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
 <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
Message-ID: <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>

On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> That's good to know. I think the tricky part is mostly about keeping track of all these disabled warnings, so they are not kept around longer than necessary. And that needs coordination with all the subtasks of the umbrella issue.
>
> Thanks for quick reaction.
> I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.

I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time.

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

PR: https://git.openjdk.java.net/jdk/pull/8599

From kbarrett at openjdk.java.net  Wed May 11 14:01:52 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 11 May 2022 14:01:52 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
Message-ID: <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>

On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid pragma error in before GCC 12

Changes requested by kbarrett (Reviewer).

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462:

> 460:    HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing
> 461:    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \
> 462:         maybe-uninitialized class-memaccess unused-result extra use-after-free

Globally disabling use-after-free warnings for this package seems really
questionable. If these are problems in the code, just suppressing the warning
and leaving the problems to bite us seems like a bad idea.  And the problems
ought to be reported upstream to the HarfBuzz folks.

src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 51:

> 49: 
> 50: #define PRAGMA_STRINGOP_OVERFLOW_IGNORED \
> 51:   PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow")

Are the reported problems with format/stringop-overflow real? Or are they
false positives? If they are real then I'm not going to approve ignoring them,
unless there is some urgent reason and there are followup bug reports for
fixing them.

src/java.base/share/native/libjli/java.c line 1629:

> 1627:         const char *arg = jargv[i];
> 1628:         if (arg[0] == '-' && arg[1] == 'J') {
> 1629:             *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2);

Wow!

src/java.base/unix/native/libjli/java_md_common.c line 135:

> 133:     if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0;
> 134:     JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd);
> 135: #pragma GCC diagnostic pop

Wouldn't it be better to just call JLI_Snprintf without the precheck and check the result to determine whether it was successful or was truncated?  I think that kind of check is supposed to make gcc's truncation checker happy.

src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c line 193:

> 191: #if defined(__GNUC__) && __GNUC__ >= 12
> 192: #pragma GCC diagnostic pop
> 193: #endif

Rather than all this warning suppression cruft and the comment explaining why
it's okay, just compute the `(strBufNextChar - strBufBegin)` offset a few
lines earlier, before the realloc.

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

PR: https://git.openjdk.java.net/jdk/pull/8646

From mullan at openjdk.java.net  Wed May 11 14:15:46 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 11 May 2022 14:15:46 GMT
Subject: RFR: 8286444: javac errors after JDK-8251329 are not helpful
 enough to find root cause
In-Reply-To: <EjOkZaKwGMRD7tnv8j2dz1V0neykKG6-ag38tfobH-Q=.7d114b54-be20-46c4-b3c7-f1dc6e774b8e@github.com>
References: <3ic255Bdgk3-0lSnzjOQN9CDgZmEDWhmTvVsWVW1VJY=.d4b147e9-e1ac-42a6-afc2-983f24b3547c@github.com>
 <UUZ1xBAT1flJ6L-ZPPjwRQZliYd8ut_PgNqBP1mCEs4=.c26b3bec-8c81-4aa7-8b21-d6522b93c653@github.com>
 <kO9pDThPzzESgtzxJDrDtYssv6ru2imP10mSpEGhOX0=.4e8fb24a-afed-45f1-b6b8-f154c0508e25@github.com>
 <w7bNUNIb4Uxht1Td8mFJxZSct6WbJovezxafpQE-XmI=.47520696-64ac-46f4-9d42-50291a1eecb9@github.com>
 <0s9v8OsanZs3YyGExi53Zw95jxz-9lOftUkHzL9902I=.19bc54ba-5947-45f5-a561-5454ffafac8d@github.com>
 <9i-SlgA0aA456BOanRru4buElqcghuXiTu3snf7OTsI=.824ac2fb-2f31-4fe9-bc1c-39ed53180520@github.com>
 <DZHQs9QGNidDZKI4OpPgoloi7CEANWltPh-kC7h83w0=.0063131f-1939-4a1a-aecf-866a2c7c789a@github.com>
 <1k3jFfLU1A0u1zxwnB7FU0qG9dxf2U5x_XijN_ZFqZ0=.7b91eec3-b638-43ae-98b6-007186f1e98f@github.com>
 <hgUaDRzCG63uA_pqcKpRkjqbaYIxnItBMEGalLq0nfY=.0f7cf288-f2c0-4e3f-99d6-d040fa3ab90e@github.com>
 <LK0Wm2DH5Bk474DqMvsnMPzB0IWGfEEukSXZTHzZEiY=.a1733ce2-0540-41fe-b3fc-db54f9a4a38b@github.com>
 <EjOkZaKwGMRD7tnv8j2dz1V0neykKG6-ag3
 8tfobH-Q=.7d114b54-be20-46c4-b3c7-f1dc6e774b8e@github.com>
Message-ID: <GnCTFaQ7Mg3vWKRSJ8yq6zieWQMTaAzzWJBv3vW-DLU=.07972a0a-d90d-4a3d-8f73-4e8fc0fe1bc3@github.com>

On Wed, 11 May 2022 05:39:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > It's probably ok, but the bug report is either incomplete or I am missing something. It says "This can be improved to something like: ..." but the same text as is emitted now is used. Can you fix this so I have a better example of what will be included in the message?
> > 
> > 
> > The bug report also says "The error message does not give a clue which jar file is causing the problem" but the error message includes the name "invalid.jar" so I am also confused about that.
> 
> There are two parts to it. In the case of initCEN method, the proposed change is to include the name of the rejected entry in the exception message. This is not the same thing as leaking a file path in the exception message so I don't think we have a concern here.

Ok, but @RealCLanger can you address the prior comments I had on the bug report? The error messages (before and after the fix) are the same.

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

PR: https://git.openjdk.java.net/jdk/pull/8616

From jpai at openjdk.java.net  Wed May 11 14:24:38 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 11 May 2022 14:24:38 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
Message-ID: <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>

> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`?
> 
> With this change the build now passes (tested both with bundled and system zlib variants).
> 
> tier1, tier2 and tier3 testing has been done and no related failures have been noticed.

Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:

 - copyright years
 - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib
 - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file
 - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8651/files
  - new: https://git.openjdk.java.net/jdk/pull/8651/files/eee12c25..081a7d34

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

  Stats: 41 lines in 5 files changed: 5 ins; 30 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8651.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8651/head:pull/8651

PR: https://git.openjdk.java.net/jdk/pull/8651

From maxim.kartashev at jetbrains.com  Wed May 11 14:29:03 2022
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Wed, 11 May 2022 17:29:03 +0300
Subject: Can JDK-8190546 be re-opened or "how do I delete a file ending with a
 space on Windows"
Message-ID: <CAG0Tb0hQUKDg5PrjFn0uTDMn-N=0LijhTm=wA+EbJa5dhaNrsQ@mail.gmail.com>

Win32 documentation [1] kind of discourages the use of space at the very
end of a file name. Based on that, JDK-8190546 (File.toPath() reject
directory names with trailing space) had been closed a long time ago. I
would like to poll the public on the matter of re-opening the bug.

There isn't anything new that I can throw in support of allowing JDK to
work with such file names. But the old points can perhaps be re-visited.
AFAIU, the only reason to explicitly forbid that (see
WindowsPathParser.normalize()) was that the parsing is based on Windows
documentation like [1]. That documentation says the following:
"Do not end a file or directory name with a space or a period. Although the
underlying file system may support such names, the Windows shell and user
interface does not"
Indeed, it's hard or even impossible to create such a file using "normal"
windows GUI, but you can use that GUI to delete such a file. In Java, you
can't do either. Working in a cygwin terminal, you can fairly easily create
a file name ending with a space. And when you turn to your Java-based IDE
to delete it, you get an error from the very basic level of NIO that you
can't overrule, which seems to be quite unfortunate.

If there's any interest in resolving this - or at least not enough
opposition to let it be resolved - I am willing to make the necessary
changes and open a PR.

References
[1]
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions
[2] https://bugs.openjdk.java.net/browse/JDK-8190546

From jvernee at openjdk.java.net  Wed May 11 14:29:19 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 14:29:19 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v8]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <ZoIhfv8XuhPgK3Yb_s14VP6aDELjzjjDA-2WUaGiC3Q=.7d1ccc21-582a-4ffd-9063-d99d27653058@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - Migrate to GrowableArray
 - Address some review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/43fd1b91..abd2b6ca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=06-07

  Stats: 254 lines in 23 files changed: 22 ins; 125 del; 107 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 14:29:25 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 14:29:25 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <9eViilPD2YEH0Lt8StEhiGJfDlMSSa1NpPC02MKItuM=.0ce2490e-9a53-46b3-a14b-ab88b4a0f3fc@github.com>

On Tue, 10 May 2022 21:02:39 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> Nice work! Looks good. Some minor comments/questions follow.

@iwanowww Thanks for the review! I've addressed most comments already, but will have to think a bit on how to handle the asynchronous exceptions issue.

> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531:
> 
>> 5529: }
>> 5530: 
>> 5531: // On 64 bit we will store integer like items to the stack as
> 
> Time for a cleanup? `64 bit` vs `64bit`, `abi`, `Aarch64`.

I've cleaned up the spaces and capitalization here a bit.

> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 36:
> 
>> 34: #include "code/nativeInst.hpp"
>> 35: #include "code/vtableStubs.hpp"
>> 36: #include "compiler/disassembler.hpp"
> 
> Redundant includes? No new code added in the file.

Good catch. Seems like a merge artifact maybe. Removing them seems to be fine.

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From kbarrett at openjdk.java.net  Wed May 11 14:31:02 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 11 May 2022 14:31:02 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
 <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
Message-ID: <DR2hvyOTMElYPvyK5c920M9wq8ZEmM5Ei_6xGd1CCME=.fb936f05-ea1c-4f4f-8b91-0427a02270b1@github.com>

On Wed, 11 May 2022 13:56:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid pragma error in before GCC 12
>
> src/java.base/share/native/libjli/java.c line 1629:
> 
>> 1627:         const char *arg = jargv[i];
>> 1628:         if (arg[0] == '-' && arg[1] == 'J') {
>> 1629:             *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2);
> 
> Wow!

I wonder if the client expects NULL strings in the result, or if the NULL value should be an empty string?  If empty strings are okay, this would be simpler without the conditional, just dup from arg + 2 to the terminating byte (which might be immediate).

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

PR: https://git.openjdk.java.net/jdk/pull/8646

From jpai at openjdk.java.net  Wed May 11 14:32:48 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 11 May 2022 14:32:48 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <SqjQt4L5AItmvC7ZzS7fXjsv0Fi7bzlYpn4KLp-eALc=.42365450-36e2-44d4-858a-5387864eb47d@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <SqjQt4L5AItmvC7ZzS7fXjsv0Fi7bzlYpn4KLp-eALc=.42365450-36e2-44d4-858a-5387864eb47d@github.com>
Message-ID: <WYm5VblGt0GG7pl4I7pg9m_JKlGoU5CaAUk95WrtifE=.07d74530-e51c-4e78-9b99-3d6a07bc3db2@github.com>

On Wed, 11 May 2022 11:52:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - copyright years
>>  - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib
>>  - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file
>>  - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code
>
> make/autoconf/lib-bundled.m4 line 224:
> 
>> 222:   LIBZ_LIBS=""
>> 223:   if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then
>> 224:     LIBZ_CFLAGS="$LIBZ_CFLAGS $APPLE_LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib"
> 
> Declaring APPLE_LIBZ_CFLAGS far away (and only conditionally) and then using it once here just makes for hard-to-read code. 
> 
> Suggestion:
> 
>     LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib"
>     if test "x$OPENJDK_TARGET_OS" = xmacosx; then
>       LIBZ_CFLAGS="$LIBZ_CFLAGS -DHAVE_UNISTD_H"
>     fi
> 
> ... and remove the assignment above.

Updated the PR to implement this suggestion

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

PR: https://git.openjdk.java.net/jdk/pull/8651

From jpai at openjdk.java.net  Wed May 11 14:32:48 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 11 May 2022 14:32:48 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <1VProTCyDpN_GDpPOkBynPmEjGkNhicS7ZINpTLYAdo=.654b6689-d3e1-42ca-b4d6-e0c324a3ce45@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <SqjQt4L5AItmvC7ZzS7fXjsv0Fi7bzlYpn4KLp-eALc=.42365450-36e2-44d4-858a-5387864eb47d@github.com>
 <tx7ovbOEUxPDOSQfQkZI03FrISR2fEEhn64j4xBeiuI=.c46c7063-119a-4fce-a934-3ef0bff84a7c@github.com>
 <1VProTCyDpN_GDpPOkBynPmEjGkNhicS7ZINpTLYAdo=.654b6689-d3e1-42ca-b4d6-e0c324a3ce45@github.com>
Message-ID: <DSCfwD6PCOtstNY32f67adjqpw8chVzzqzj28ZEwB7E=.977faf26-898a-4e45-8572-0cee04d11f53@github.com>

On Wed, 11 May 2022 12:50:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thank you for these useful inputs Magnus. I did these changes locally but for some reason this format-nonliteral is not getting picked up while building that library. I will investigate and see what's going on. Will update the PR once I figure it out.
>
> I agree with Magnus and try to avoid changing the imported zlib code.

>  I did these changes locally but for some reason this format-nonliteral is not getting picked up while building that library.

Turns out that was slightly inaccurate. What was actually happening was that, that setting you suggested in that build file did indeed work and got picked up. But it ran into an error which looked like:


src/java.base/share/native/libzip/zlib/gzwrite.c:452:40: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
    len = vsnprintf(next, state->size, format, va);
                                       ^~~~~~

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

PR: https://git.openjdk.java.net/jdk/pull/8651

From jvernee at openjdk.java.net  Wed May 11 14:33:56 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 14:33:56 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <zCv3AQoTrDLchF5553FpJDjwvDx8KGuCbWOEDU6ezT0=.3a5cfd8f-ac88-43a5-a3f8-65248154a777@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <zCv3AQoTrDLchF5553FpJDjwvDx8KGuCbWOEDU6ezT0=.3a5cfd8f-ac88-43a5-a3f8-65248154a777@github.com>
Message-ID: <KJcbKhmJ1NGzEgWiYfYMTOFfuXgDb5Oe25vi9qKWlsE=.ceda547a-9513-4e03-8e39-6fcc0cc77d92@github.com>

On Wed, 11 May 2022 11:06:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/share/opto/callGenerator.cpp line 1131:
>> 
>>> 1129: 
>>> 1130:     case vmIntrinsics::_linkToNative:
>>> 1131:     print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(),
>> 
>> Why is it unconditionally reported as inlining failure?
>
> The call that is being processed here is `linkToNative`, and that call is not inlined, so reporting an inlining failure seems correct. We still go through the method handle trampoline stub which loads the actual target from the NativeEntryPoint appendix argument (`jump_to_native_invoker` in methodHandles_x86.cpp).
> 
> It's potentially faster here to generate a runtime call to the underlying invoker/downcall stub if the NativeEntryPoint is constant (i.e. avoid the lookup through NEP in the MH trampoline), but I hadn't gotten to investigating that yet.
> 
> From comparing the benchmark times between this and the old implementation (which generated an inline call), they are not all that different. So it seemed that doing something special here would not save that much time any ways. (but, still would be good to investigate at some point)

I've filed: https://bugs.openjdk.java.net/browse/JDK-8286588

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 14:34:02 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 14:34:02 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
Message-ID: <1xENEcoejLZmUfLYTJsJ-nUWF9dlZ3BdXdpvSU_JoPk=.8efe4cde-cdc1-4174-a4a2-5437464f55d2@github.com>

On Tue, 10 May 2022 20:38:05 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/share/prims/foreign_globals.cpp line 217:
> 
>> 215: 
>> 216:  public:
>> 217:   ForeignCMO(int total_in_args, const VMRegPair* in_regs, int total_out_args, VMRegPair* out_regs,
> 
> I propose to turn it into a trivial ctor and move all the logic into a helper static function which returns the computed moves.

Done. Moved constructor logic into a `compute` method, and added a static helper that constructs a ComputeMoveOrder, calls `compute`, and then returns the moves.

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

PR: https://git.openjdk.java.net/jdk/pull/7959

From asotona at openjdk.java.net  Wed May 11 13:41:30 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:41:30 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v4]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <3RgMbsaSwgdBXE2qlIwjVI680aN7Ovi6OOfu9eeNtJo=.a76eff60-8652-40ce-ae40-20f9095b1b93@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona 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 six additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/f0729396..a59dfa4f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=02-03

  Stats: 9179 lines in 255 files changed: 5253 ins; 2422 del; 1504 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 13:41:30 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 13:41:30 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
 <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
 <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>
Message-ID: <6EkEbNxPc3RKNGprHlBhqM574oY7iPI9z3PpR91IMok=.9019963f-8085-49a8-951f-f8a2b2137fb0@github.com>

On Wed, 11 May 2022 13:31:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thanks for quick reaction.
>> I'll keep my eyes on this race of patches and update this pull request accordingly or create a new PR.
>
> I put out a PR for java.base, but thought I'd wait until the javac fixe were pushed before integrating and would re-enable the warnings at the same time.

Feel free to go ahead with the java.base PR as this one still needs CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Wed May 11 14:45:12 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 14:45:12 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v5]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <cJu_ULWgPS-KxeOlGeUXs0iYI7U7DjdxrITrg0vzoTQ=.057010a4-d66f-4df7-b982-7e0bee3519c4@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/a59dfa4f..32282515

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From lancea at openjdk.java.net  Wed May 11 15:03:47 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 11 May 2022 15:03:47 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <DSCfwD6PCOtstNY32f67adjqpw8chVzzqzj28ZEwB7E=.977faf26-898a-4e45-8572-0cee04d11f53@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <SqjQt4L5AItmvC7ZzS7fXjsv0Fi7bzlYpn4KLp-eALc=.42365450-36e2-44d4-858a-5387864eb47d@github.com>
 <tx7ovbOEUxPDOSQfQkZI03FrISR2fEEhn64j4xBeiuI=.c46c7063-119a-4fce-a934-3ef0bff84a7c@github.com>
 <1VProTCyDpN_GDpPOkBynPmEjGkNhicS7ZINpTLYAdo=.654b6689-d3e1-42ca-b4d6-e0c324a3ce45@github.com>
 <DSCfwD6PCOtstNY32f67adjqpw8chVzzqzj28ZEwB7E=.977faf26-898a-4e45-8572-0cee04d11f53@github.com>
Message-ID: <8QwcHX46TZ4lK5rWWftn_gzLbN7ErqkeV2wz1wGlOMw=.63e28371-2f39-4699-83db-3ffb447c6f8f@github.com>

On Wed, 11 May 2022 14:25:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I agree with Magnus and try to avoid changing the imported zlib code.
>
>>  I did these changes locally but for some reason this format-nonliteral is not getting picked up while building that library.
> 
> Turns out that was slightly inaccurate. What was actually happening was that, that setting you suggested in that build file did indeed work and got picked up. But it ran into an error which looked like:
> 
> 
> src/java.base/share/native/libzip/zlib/gzwrite.c:452:40: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
>     len = vsnprintf(next, state->size, format, va);
>                                        ^~~~~~

> I agree with Magnus and try to avoid changing the imported zlib code.

We already had modified gzwrite.c in our port so I thought keeping the changes narrowed to apple made sense here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8651

From psandoz at openjdk.java.net  Wed May 11 15:07:57 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 11 May 2022 15:07:57 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <Z8meMXznUI2sBBFeON_F668Mq46tMOiRRkSnyu99igA=.ec466e89-bca0-4e54-8974-e6fc708ace49@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <PAbHd6tldh6Is0PsXN3l5gzVGugeU9aXERzFEdFOWCE=.c19b875b-50ec-4c08-a75d-cd23d27e2bfa@github.com>
 <Z8meMXznUI2sBBFeON_F668Mq46tMOiRRkSnyu99igA=.ec466e89-bca0-4e54-8974-e6fc708ace49@github.com>
Message-ID: <4LG2tZgoxvuaUEi78DyUrMbI9dIOM8CPk7GbkpZtp6M=.49894db1-a271-47a1-b8dc-68a1d5f46915@github.com>

On Wed, 11 May 2022 03:23:13 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> I modified the code of this PR to avoid the conversion of `boolean` to `int`, so a constant integer value is passed all the way through, and the masked load is made intrinsic from the method at which the constants are passed as arguments i.e. the public `fromArray` mask accepting method.
>
> Hi @PaulSandoz , thanks for the patch for the constant int parameter. I think the main change is:
> 
> -    ByteVector fromArray0Template(Class<M> maskClass, C base, long offset, int index, M m, boolean offsetInRange,
> +    ByteVector fromArray0Template(Class<M> maskClass, C base, long offset, int index, M m, int offsetInRange,
>                          VectorSupport.LoadVectorMaskedOperation<C, ByteVector, ByteSpecies, M> defaultImpl) {
>          m.check(species());
>          ByteSpecies vsp = vspecies();
> -        if (offsetInRange) {
> -            return VectorSupport.loadMasked(
> -                vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(),
> -                base, offset, m, /* offsetInRange */ 1,
> -                base, index, vsp, defaultImpl);
> -        } else {
> -            return VectorSupport.loadMasked(
> -                vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(),
> -                base, offset, m, /* offsetInRange */ 0,
> -                base, index, vsp, defaultImpl);
> -        }
> +        return VectorSupport.loadMasked(
> +            vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(),
> +            base, offset, m, offsetInRange == 1 ? 1 : 0,
> +            base, index, vsp, defaultImpl);
>      }
> 
> which uses `offsetInRange == 1 ? 1 : 0`. Unfortunately this could not always make sure the `offsetInRange` a constant a the compiler time. Again, this change could also make the assertion fail randomly:
> 
> --- a/src/hotspot/share/opto/vectorIntrinsics.cpp
> +++ b/src/hotspot/share/opto/vectorIntrinsics.cpp
> @@ -1236,6 +1236,7 @@ bool LibraryCallKit::inline_vector_mem_masked_operation(bool is_store) {
>      } else {
>        // Masked vector load with IOOBE always uses the predicated load.
>        const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int();
> +      assert(offset_in_range->is_con(), "must be a constant");
>        if (!offset_in_range->is_con()) {
>          if (C->print_intrinsics()) {
>            tty->print_cr("  ** missing constant: offsetInRange=%s",
> 
> Sometimes, the compiler can parse it a constant. I think this depends on the compiler OSR and speculative optimization. Did you try an example with IOOBE on a non predicated hardware?
> 
> Here is the main code of my unittest to reproduce the issue:
> 
> static final VectorSpecies<Integer> I_SPECIES = IntVector.SPECIES_128;
> static final int LENGTH = 1026;
> public static int[] ia;
> public static int[] ib;
> 
> private static void init() {
>         for (int i = 0; i < LENGTH; i++) {
>             ia[i] = i;
>             ib[i] = 0;
>         }
> 
>         for (int i = 0; i < 2; i++) {
>             m[i] = i % 2 == 0;
>         }
> }
> 
>  private static void func() {
>         VectorMask<Integer> mask = VectorMask.fromArray(I_SPECIES, m, 0);
>         for (int i = 0; i < LENGTH; i += vl) {
>             IntVector av = IntVector.fromArray(I_SPECIES, ia, i, mask);
>             av.lanewise(VectorOperators.ABS).intoArray(ic, i, mask);
>         }
>  }
> 
>  public static void main(String[] args) {
>         init();
>         for (int i = 0; i < 10000; i++) {
>             func();
>         }
>   }

@XiaohongGong Doh! The ternary was an experiment, and I forgot to re-run the code gen script before sending your the patch. See `IntVector`, which does not have that. I presume when the offset is not in range and the other code path is taken then it might be problematic unless all code paths are inlined. I will experiment further with tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From lancea at openjdk.java.net  Wed May 11 15:12:05 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 11 May 2022 15:12:05 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
Message-ID: <Ift_rcraR8e0IeaIz_GPSyo_41bMmqpSdCZqshJ_cGs=.fa1f6941-92cf-4315-96bb-ce57c7004ac2@github.com>

On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`?
>> 
>> With this change the build now passes (tested both with bundled and system zlib variants).
>> 
>> tier1, tier2 and tier3 testing has been done and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - copyright years
>  - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib
>  - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file
>  - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code

Hi Jai,

thank you for continuing the work to allow us to build/use the bundled zlib on macOS 

we should also update: open/src/java.base/share/native/libzip/zlib/ChangeLog to add a comment regarding why the build changes were required

make/autoconf/lib-bundled.m4 line 220:

> 218:   if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then
> 219:     LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib"
> 220:     if test "x$OPENJDK_TARGET_OS" = xmacosx; then

Please add a comment here as to why we are doing this

make/modules/java.base/lib/CoreLibraries.gmk line 139:

> 137:     DISABLED_WARNINGS_gcc := unused-function implicit-fallthrough, \
> 138:     DISABLED_WARNINGS_clang := format-nonliteral, \
> 139:     LDFLAGS := $(LDFLAGS_JDKLIB) \

A comment would be good here also as to the reasoning

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 683:

> 681:   ifeq ($(USE_EXTERNAL_LIBZ), false)
> 682:     LIBSPLASHSCREEN_EXTRA_SRC += java.base:libzip/zlib
> 683:     LIBZ_DISABLED_WARNINGS_CLANG := format-nonliteral

Same here for a comment

-------------

PR: https://git.openjdk.java.net/jdk/pull/8651

From psandoz at openjdk.java.net  Wed May 11 15:14:49 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 11 May 2022 15:14:49 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store
In-Reply-To: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
Message-ID: <72MBdW0hFE0o2NLg2I94Zw7y-ZJ7-SGVh5Pjz9mmOGI=.31b44f50-547a-4d79-a355-2705d0e8869e@github.com>

On Tue, 10 May 2022 01:23:55 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
> 
> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
> 
> Benchmark                                   Before    After     Gain Units
> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
> 
> Similar performane gain can also be observed on ARM hardware.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 4086:

> 4084:         } else {
> 4085:             $Type$Species vsp = vspecies();
> 4086:             if (offset < 0 || offset > (a.length - vsp.length())) {

Can we use `VectorIntrinsics.checkFromIndexSize`? e.g. 

if (!VectorIntrinsics.checkFromIndexSize(offset, vsp.length(), a.length)) { ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From jvernee at openjdk.java.net  Wed May 11 15:24:39 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 15:24:39 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v9]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <KtWT9_w2kUtsr3ETTbQV68ydwMmz133sEZb9cEsFFFM=.c6611bdf-2d54-4f8b-9261-aa9d027e4ff6@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Fix use of rt_call

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/abd2b6ca..c6754a1c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From bpb at openjdk.java.net  Wed May 11 15:32:59 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 11 May 2022 15:32:59 GMT
Subject: RFR: 8286287: Reading file as UTF-16 causes Error which
 "shouldn't happen"
In-Reply-To: <oCWtLqDR1Wh8DCeIeCdLExXp9JXEPZ2LMODfe0FDaZs=.03d127d4-316d-4be0-96fc-fbfe61031dd4@github.com>
References: <oCWtLqDR1Wh8DCeIeCdLExXp9JXEPZ2LMODfe0FDaZs=.03d127d4-316d-4be0-96fc-fbfe61031dd4@github.com>
Message-ID: <OivewV12uEo6LFkzXWascBs1DfRYTrtR2gzeY1acV4Y=.ea99d8db-9ed8-45fe-862a-17b6fc38094e@github.com>

On Tue, 10 May 2022 20:22:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter replaces on malformed/unmappable characters with replacements. However, there was a code path that lacked to set the `CodingErrorAction.REPLACE` on the decoder. Unrelated, one typo in a test was also fixed.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8640

From brian.burkhalter at oracle.com  Wed May 11 15:35:57 2022
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 11 May 2022 15:35:57 +0000
Subject: Can JDK-8190546 be re-opened or "how do I delete a file ending
 with a space on Windows"
In-Reply-To: <CAG0Tb0hQUKDg5PrjFn0uTDMn-N=0LijhTm=wA+EbJa5dhaNrsQ@mail.gmail.com>
References: <CAG0Tb0hQUKDg5PrjFn0uTDMn-N=0LijhTm=wA+EbJa5dhaNrsQ@mail.gmail.com>
Message-ID: <B056E60B-A54A-4701-8376-D5685B263A0E@oracle.com>

Redirect discussion to nio-dev.

Brian

> On May 11, 2022, at 7:29 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com> wrote:
> 
> Win32 documentation [1] kind of discourages the use of space at the very
> end of a file name. Based on that, JDK-8190546 (File.toPath() reject
> directory names with trailing space) had been closed a long time ago. I
> would like to poll the public on the matter of re-opening the bug.
> 
> There isn't anything new that I can throw in support of allowing JDK to
> work with such file names. But the old points can perhaps be re-visited.
> AFAIU, the only reason to explicitly forbid that (see
> WindowsPathParser.normalize()) was that the parsing is based on Windows
> documentation like [1]. That documentation says the following:
> "Do not end a file or directory name with a space or a period. Although the
> underlying file system may support such names, the Windows shell and user
> interface does not"
> Indeed, it's hard or even impossible to create such a file using "normal"
> windows GUI, but you can use that GUI to delete such a file. In Java, you
> can't do either. Working in a cygwin terminal, you can fairly easily create
> a file name ending with a space. And when you turn to your Java-based IDE
> to delete it, you get an error from the very basic level of NIO that you
> can't overrule, which seems to be quite unfortunate.
> 
> If there's any interest in resolving this - or at least not enough
> opposition to let it be resolved - I am willing to make the necessary
> changes and open a PR.
> 
> References
> [1]
> https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions
> [2] https://bugs.openjdk.java.net/browse/JDK-8190546


From clanger at openjdk.java.net  Wed May 11 15:39:11 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 11 May 2022 15:39:11 GMT
Subject: RFR: 8286594: (zipfs) Improvements after JDK-8251329
Message-ID: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com>

This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements.

It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode:nameAsString() to return the node name as a String.

-------------

Commit messages:
 - JDK-8286594

Changes: https://git.openjdk.java.net/jdk/pull/8655/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8655&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286594
  Stats: 73 lines in 1 file changed: 31 ins; 38 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8655.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8655/head:pull/8655

PR: https://git.openjdk.java.net/jdk/pull/8655

From jvernee at openjdk.java.net  Wed May 11 15:47:11 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 15:47:11 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
Message-ID: <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>

On Wed, 11 May 2022 12:05:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306:
>> 
>>> 304:   intptr_t exception_handler_offset = __ pc() - start;
>>> 305: 
>>> 306:   // Native caller has no idea how to handle exceptions,
>> 
>> Can you elaborate, please, how it is expected to work in presence of asynchronous exceptions? I'd expect to see a code which unconditionally clears pending exception with an assertion that verifies that the exception is of expected type.
>
> We have an exception handler in Java as well, so this code is only a fail safe. But, I think in the case of asynchronous exceptions this might be problematic if the exception is discovered by the current thread outside of the Java exception handler, turned into a synchronous exception and then we get here and call `ProgrammableUpcallhandler::handle_uncaught_exception` and then crash. Or if the asynchronous exception is discovered in `ProgrammableUpcallHandler::on_exit` (where there is currently an assert for no exceptions).
> 
> I think you're right that, in both of those cases, if the exception is asynchronous, we should just ignore it.

Discussed this with Maurizio as well. 

My understanding is as follows:
1. Async exceptions are installed into a thread's `pending_exception` field by handshake at a safepoint
2. From there they are "thrown" (I guess during the same safepoint?), in which case we either end up in a user-defined exception handler (higher up the stack), in our Java fallback exception handler (print stack trace and terminate), or in this fallback exception handler (print and terminate).
3. If we end up in this exception handler it means the async exception was installed somewhere outside of our Java exception handler and "thrown" from there. However, it also means that the Java code we were calling into completed abruptly.
4. We've previously established that we have no way of signalling to the native code that is calling us that something went wrong, and so the only safe option is to terminate, as to not leave the application in an inconsistent state.

As a consequence, I don't think we have much choice in the case of async exceptions if we get here. Silently clearing them seems like it will leave the program in an inconsistent state (since we unwound some frames), so we have to terminate I think.

(@dholmes-ora is my understanding of async exceptions in point 1. and 2. correct here?)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 15:47:12 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 15:47:12 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v9]
In-Reply-To: <kQkdmddPF36nfoOCR4zkE-uKuHQByHkXxfdz0xdoaBc=.eeb14892-9d42-4ac1-854e-58b9401290d0@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <SSI4EbbwAEFokP_lQ3ET9TZRNzxEC6DHZ2_hvQft3eo=.70763ae0-6260-40f7-99d5-6bd151a70ee4@github.com>
 <F0kIhISiVv7a-ST9aj9bMEe7o3kXcGdYcaL8TLj6o5Y=.623c3848-179d-4dee-8ea2-61cf185a8a2d@github.com>
 <kQkdmddPF36nfoOCR4zkE-uKuHQByHkXxfdz0xdoaBc=.eeb14892-9d42-4ac1-854e-58b9401290d0@github.com>
Message-ID: <RQnZbOaV4sMbxSMmZkfCHf1RoAcadQ_ZC1iC1Gs27t0=.33257ecf-9255-4c5c-ba61-ea1759405d78@github.com>

On Wed, 11 May 2022 12:20:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Any problems with migrating `CallConv` and `RegSpiller`away from ` VMReg* + int` to `GrowableArray<VMReg>`?
>
> I'll try migrating to `GrowableArray`

Done. I've removed these accessors as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From naoto at openjdk.java.net  Wed May 11 15:52:59 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 15:52:59 GMT
Subject: RFR: 8286287: Reading file as UTF-16 causes Error which
 "shouldn't happen" [v2]
In-Reply-To: <oCWtLqDR1Wh8DCeIeCdLExXp9JXEPZ2LMODfe0FDaZs=.03d127d4-316d-4be0-96fc-fbfe61031dd4@github.com>
References: <oCWtLqDR1Wh8DCeIeCdLExXp9JXEPZ2LMODfe0FDaZs=.03d127d4-316d-4be0-96fc-fbfe61031dd4@github.com>
Message-ID: <1ACSHj207It-Cy4zwdn2VjMI5GBE3BfTyBhLj4_d_X8=.255d3275-b6ba-4b05-9a70-5d93324b7c7e@github.com>

> `String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter replaces on malformed/unmappable characters with replacements. However, there was a code path that lacked to set the `CodingErrorAction.REPLACE` on the decoder. Unrelated, one typo in a test was also fixed.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Reverted the typo fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8640/files
  - new: https://git.openjdk.java.net/jdk/pull/8640/files/0fa7cd38..d5a29e2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8640&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8640&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8640.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8640/head:pull/8640

PR: https://git.openjdk.java.net/jdk/pull/8640

From mkartashev at openjdk.java.net  Wed May 11 16:03:54 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Wed, 11 May 2022 16:03:54 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
Message-ID: <Qs8Wm4J27rP2T1O2OJVMQk059XiFUT5I3mpp1bHKRMI=.defc31d7-0e77-4c54-bdba-eac38106647a@github.com>

On Wed, 4 May 2022 08:00:08 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently we set _WIN32_WINNT at various places in the codebase; this is used to target a minimum Windows version we want to support. See also for more detailled information :
>> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers?redirectedfrom=MSDN#setting-winver-or-_win32_winnt
>> Macros for Conditional Declarations
>> "Certain functions that depend on a particular version of Windows are declared using conditional code. This enables you to use the compiler to detect whether your application uses functions that are not supported on its target version(s) of Windows."
>> 
>> However currently we have quite a lot of differing settings of _WIN32_WINNT in the codebase ; setting _WIN32_WINNT to 0x0601 (Windows 7) where possible would make sense because we have this setting already at   java_props_md.c  (so targeting older Windows versions at other places is most likely not useful).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust API level to Windows 8 for security.cpp and do some cleanup

This change seem to have made this group of declarations obsolete: 
`src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link](
https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From pchilanomate at openjdk.java.net  Wed May 11 16:24:02 2022
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 11 May 2022 16:24:02 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
 <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
Message-ID: <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>

On Wed, 11 May 2022 15:44:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> We have an exception handler in Java as well, so this code is only a fail safe. But, I think in the case of asynchronous exceptions this might be problematic if the exception is discovered by the current thread outside of the Java exception handler, turned into a synchronous exception and then we get here and call `ProgrammableUpcallhandler::handle_uncaught_exception` and then crash. Or if the asynchronous exception is discovered in `ProgrammableUpcallHandler::on_exit` (where there is currently an assert for no exceptions).
>> 
>> I think you're right that, in both of those cases, if the exception is asynchronous, we should just ignore it.
>
> Discussed this with Maurizio as well. 
> 
> My understanding is as follows:
> 1. Async exceptions are installed into a thread's `pending_exception` field by handshake at a safepoint
> 2. From there they are "thrown" (I guess during the same safepoint?), in which case we either end up in a user-defined exception handler (higher up the stack), in our Java fallback exception handler (print stack trace and terminate), or in this fallback exception handler (print and terminate).
> 3. If we end up in this exception handler it means the async exception was installed somewhere outside of our Java exception handler and "thrown" from there. However, it also means that the Java code we were calling into completed abruptly.
> 4. We've previously established that we have no way of signalling to the native code that is calling us that something went wrong, and so the only safe option is to terminate, as to not leave the application in an inconsistent state.
> 
> As a consequence, I don't think we have much choice in the case of async exceptions if we get here. Silently clearing them seems like it will leave the program in an inconsistent state (since we unwound some frames), so we have to terminate I think.
> 
> (@dholmes-ora is my understanding of async exceptions in point 1. and 2. correct here?)

If you want to avoid processing asynchronous exceptions during this upcall you could block them (check NoAsyncExceptionDeliveryMark in JavaThread::exit()). Seems you could set the flag in ProgrammableUpcallhandler::on_entry() and unset it back on ProgrammableUpcallhandler::on_exit(). While that flag is set any asynchronous exception in the handshake queue of this thread will be skipped from processing. Maybe we should add a public method in the JavaThread class, block_async_exceptions()/unblock_async_exceptions() so we hide the handshake implementation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From rriggs at openjdk.java.net  Wed May 11 16:27:02 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 16:27:02 GMT
Subject: RFR: 8286287: Reading file as UTF-16 causes Error which
 "shouldn't happen" [v2]
In-Reply-To: <1ACSHj207It-Cy4zwdn2VjMI5GBE3BfTyBhLj4_d_X8=.255d3275-b6ba-4b05-9a70-5d93324b7c7e@github.com>
References: <oCWtLqDR1Wh8DCeIeCdLExXp9JXEPZ2LMODfe0FDaZs=.03d127d4-316d-4be0-96fc-fbfe61031dd4@github.com>
 <1ACSHj207It-Cy4zwdn2VjMI5GBE3BfTyBhLj4_d_X8=.255d3275-b6ba-4b05-9a70-5d93324b7c7e@github.com>
Message-ID: <cBsaJrh51RBitK8ys1Qxpur7wdDSzWBsYCRYMGzqk6k=.b40261df-8f8c-4898-8081-2cb97bf31adb@github.com>

On Wed, 11 May 2022 15:52:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> `String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter replaces on malformed/unmappable characters with replacements. However, there was a code path that lacked to set the `CodingErrorAction.REPLACE` on the decoder. Unrelated, one typo in a test was also fixed.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverted the typo fix

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8640

From rriggs at openjdk.java.net  Wed May 11 16:30:41 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 16:30:41 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyrights
  Fixed cast style to add a space after cast, (where consistent with file style)
  Improved code per review comments in PollSelectors.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8642/files
  - new: https://git.openjdk.java.net/jdk/pull/8642/files/7ff806a5..a6679ce7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=01-02

  Stats: 41 lines in 24 files changed: 0 ins; 0 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642

PR: https://git.openjdk.java.net/jdk/pull/8642

From naoto at openjdk.java.net  Wed May 11 16:37:34 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 16:37:34 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v3]
In-Reply-To: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
Message-ID: <IOMAAfwFyiCoZbVNm4_X3VywOglN6lzOXY6RsziejBA=.6e79cd95-7fff-44d0-b0bd-dd44897f6c76@github.com>

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Allowed round-trips for offset-style ZoneIds.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/81a806e5..fcdaf512

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=01-02

  Stats: 133 lines in 3 files changed: 70 ins; 61 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Wed May 11 16:40:48 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 16:40:48 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v3]
In-Reply-To: <wluLyGYv6WoSD95I3xa0n-F0KX7NUo63BxuaHaMH7sg=.bad6f2bb-5d6d-4ae3-8d21-5c50aa32146a@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <ABcvJDzCIRi4XaSaASXbB8fxcJXuyIODjxGO5J9oh0E=.7c7c2beb-bd96-4982-99e0-e19e5d4b2979@github.com>
 <RfUh38_pnxkBdxx4cK-arebwVhHR1uis66X-RY6qQNE=.db1ef511-da45-4a12-8b51-7e9dae583ee1@github.com>
 <mfZeLSSl_CD21dZhIz4YDlVFOk7Nz5UOR4XRhF9yOUc=.a2319b8c-cd28-4df1-bddb-121e85ecc6a1@github.com>
 <0w73_YddkD3sWCUqC6EsEue-oOCZyxvPqWJA2QSZgCY=.8700718e-64b2-4781-8e54-f5e5a838291d@github.com>
 <wluLyGYv6WoSD95I3xa0n-F0KX7NUo63BxuaHaMH7sg=.bad6f2bb-5d6d-4ae3-8d21-5c50aa32146a@github.com>
Message-ID: <couzYTCOCsxdm9FaWWHWY6KKlAjzgEqJhj3YRAkl3dA=.bf7ec359-bf29-480f-bb58-6cffb5d1c8a2@github.com>

On Wed, 11 May 2022 09:00:45 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> I tried it out: If you create a ZoneId with prefixes "UT" and "UTC", they fail to convert to TimeZone. Same happens if you use this as String name in `TimeZone#getTimeZone(String)`. This is another bug / missing feature! It does not work with or without this PR.
>
> In short, we can only test what works. The test was mainly added to allow roundtrips of `ZoneOffset` instances.

The code intended to allow only offset-style ids that start with `GMT` (which is compatible with TimeZone's CustomID). Now I made changes to allow all offset-style zone ids.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From jvernee at openjdk.java.net  Wed May 11 16:42:59 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 16:42:59 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
 <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
 <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>
Message-ID: <T73dHwsxmGWzDhJzzaLzEkOpsi6LB7jHBwcBI-JTJlY=.3929d080-0ae2-4645-88db-f5dfa8f0e855@github.com>

On Wed, 11 May 2022 16:20:32 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Discussed this with Maurizio as well. 
>> 
>> My understanding is as follows:
>> 1. Async exceptions are installed into a thread's `pending_exception` field by handshake at a safepoint
>> 2. From there they are "thrown" (I guess during the same safepoint?), in which case we either end up in a user-defined exception handler (higher up the stack), in our Java fallback exception handler (print stack trace and terminate), or in this fallback exception handler (print and terminate).
>> 3. If we end up in this exception handler it means the async exception was installed somewhere outside of our Java exception handler and "thrown" from there. However, it also means that the Java code we were calling into completed abruptly.
>> 4. We've previously established that we have no way of signalling to the native code that is calling us that something went wrong, and so the only safe option is to terminate, as to not leave the application in an inconsistent state.
>> 
>> As a consequence, I don't think we have much choice in the case of async exceptions if we get here. Silently clearing them seems like it will leave the program in an inconsistent state (since we unwound some frames), so we have to terminate I think.
>> 
>> (@dholmes-ora is my understanding of async exceptions in point 1. and 2. correct here?)
>
> If you want to avoid processing asynchronous exceptions during this upcall you could block them (check NoAsyncExceptionDeliveryMark in JavaThread::exit()). Seems you could set the flag in ProgrammableUpcallhandler::on_entry() and unset it back on ProgrammableUpcallhandler::on_exit(). While that flag is set any asynchronous exception in the handshake queue of this thread will be skipped from processing. Maybe we should add a public method in the JavaThread class, block_async_exceptions()/unblock_async_exceptions() so we hide the handshake implementation.

Oh nice! I was just thinking that the only possible way out of this conundrum would be to somehow block the delivery of async exceptions (at least outside of the user's exception handler). So, that seems to be exactly what we need :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From chen.j.patrick at gmail.com  Wed May 11 14:08:28 2022
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Wed, 11 May 2022 16:08:28 +0200
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v3]
In-Reply-To: <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
 <eifrDzFJRPbvBKhIxS3VIXV9GNSaMMBDf4q53vmEVvw=.e5e3cfbb-a894-488e-9416-1067be73c810@github.com>
 <KY5Ya0MQB_OK8SgR_rVF7iB-CWPNgWU1A44IjR40bvg=.e333e601-d7da-44d2-b008-2d2d9c26b685@github.com>
 <-8CgxT4vvRlhZz5gaAcim25sJ85oPlCDYoYZxHF879c=.5d08eb77-3b52-4e8d-84ff-ae55ab487b22@github.com>
 <8HMxXhqZLI1LlaWQp0NkiLXJsHoeXxOuKY6uFyPMNRM=.77c9f6f4-a58f-41da-86d6-f615fdf0bda8@github.com>
 <dgY-0m2tjBC_KNqQmiMDb4VJzrS_m5vjamdP4J1J6sk=.3620563b-0170-4e3b-8edc-ed154b5f2927@github.com>
 <eBtTimIKT1ZsRwVd8woMwtHHRvqcWGUzBsMJVI6eACU=.ca2c9d89-1883-44e8-9765-77696c2f7542@github.com>
Message-ID: <CANmuJ8v0gP5n2fBqvdLT3k-YN9Sc-cvsvWqgvu+c1e2YYvY5rw@mail.gmail.com>

I checked you pr look good to me @Roger

Le mer. 11 mai 2022 ? 15:35, Roger Riggs <rriggs at openjdk.java.net> a ?crit :

> On Wed, 11 May 2022 13:27:38 GMT, Adam Sotona <asotona at openjdk.org> wrote:
>
> >> That's good to know. I think the tricky part is mostly about keeping
> track of all these disabled warnings, so they are not kept around longer
> than necessary. And that needs coordination with all the subtasks of the
> umbrella issue.
> >
> > Thanks for quick reaction.
> > I'll keep my eyes on this race of patches and update this pull request
> accordingly or create a new PR.
>
> I put out a PR for java.base, but thought I'd wait until the javac fixe
> were pushed before integrating and would re-enable the warnings at the same
> time.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/8599
>

From naoto at openjdk.java.net  Wed May 11 17:04:41 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 17:04:41 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v4]
In-Reply-To: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
Message-ID: <1zSZc32pEuDhOtIfc1t1svegXZ_Ty3cUVSBnQkWpIDA=.ef77de25-0da2-4ca0-85a3-4449c46ad870@github.com>

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Minor fixup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/fcdaf512..9722decd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=02-03

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

PR: https://git.openjdk.java.net/jdk/pull/8606

From bpb at openjdk.java.net  Wed May 11 17:11:46 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 11 May 2022 17:11:46 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
Message-ID: <M8J7eiMXE_ic0gKwIkiKrfJ-F-CYmnfhm9Naq1Q20aM=.d19d5079-b6cd-41b4-92ad-9e1ac06d3009@github.com>

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyrights
>   Fixed cast style to add a space after cast, (where consistent with file style)
>   Improved code per review comments in PollSelectors.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From jvernee at openjdk.java.net  Wed May 11 17:51:31 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 17:51:31 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v10]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <JcFdQwOApAPaDk0YR_iAJLZ-KUBXT3KPz0LJaJU0XCA=.b095806e-5e87-4d52-a17b-762756169f2c@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Block async exceptions during upcalls
 - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
 - Fix use of rt_call
 - Migrate to GrowableArray
 - Address some review comments
 - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
 - Remove unneeded ComputeMoveOrder
 - Remove comment about native calls in lcm.cpp
 - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
   
   Reviewed-by: jvernee, mcimadamore
 - Update riscv and arm stubs
 - ... and 16 more: https://git.openjdk.java.net/jdk/compare/cdd006e7...b29ad8f4

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7959/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=09
  Stats: 6870 lines in 157 files changed: 2596 ins; 3218 del; 1056 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Wed May 11 17:58:46 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 May 2022 17:58:46 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <T73dHwsxmGWzDhJzzaLzEkOpsi6LB7jHBwcBI-JTJlY=.3929d080-0ae2-4645-88db-f5dfa8f0e855@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
 <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
 <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>
 <T73dHwsxmGWzDhJzzaLzEkOpsi6LB7jHBwcBI-JTJlY=.3929d080-0ae2-4645-88db-f5dfa8f0e855@github.com>
Message-ID: <AIN9VRXcDj-YKtSkychFW7_ZqXdx3AsWmeMnvzJchl8=.680b9133-929d-4a47-809a-2a654a94bf26@github.com>

On Wed, 11 May 2022 16:38:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> If you want to avoid processing asynchronous exceptions during this upcall you could block them (check NoAsyncExceptionDeliveryMark in JavaThread::exit()). Seems you could set the flag in ProgrammableUpcallhandler::on_entry() and unset it back on ProgrammableUpcallhandler::on_exit(). While that flag is set any asynchronous exception in the handshake queue of this thread will be skipped from processing. Maybe we should add a public method in the JavaThread class, block_async_exceptions()/unblock_async_exceptions() so we hide the handshake implementation.
>
> Oh nice! I was just thinking that the only possible way out of this conundrum would be to somehow block the delivery of async exceptions (at least outside of the user's exception handler). So, that seems to be exactly what we need :)

I went ahead and implemented this suggestion. Now we block async exceptions in on_entry, and unblock in on_exit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From rriggs at openjdk.java.net  Wed May 11 18:11:11 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 18:11:11 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v7]
In-Reply-To: <LKptirNLwO_uCgREMY_itJbn7mdfKx7pTMq3l7emPnI=.c02a641c-ffab-4594-8a21-5ff203457147@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <LKptirNLwO_uCgREMY_itJbn7mdfKx7pTMq3l7emPnI=.c02a641c-ffab-4594-8a21-5ff203457147@github.com>
Message-ID: <JI4Stg3ZRsWu2K5T8ld1wr8KjrAvKCJfjSlZLQI5b5k=.28ad620b-07d4-41c5-b8d0-1041b253ca02@github.com>

On Mon, 9 May 2022 12:30:19 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into 8285517
>  - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>  - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>  - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>  - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>  - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>  - 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 68:

> 66:     private static final Map<String,String> theUnmodifiableEnvironment;
> 67:     static final int MIN_NAME_LENGTH = 0;
> 68:     private static final Charset jnuCharset = StaticProperty.jnuCharset();

Since the Charset is cached in StaticProperty, I don't think its worthwhile to make a local copy of the same ref.
Just refer to `StaticProperty.jnuCharset()` where it is needed.  (Here and in ProcessImpl)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From ihse at openjdk.java.net  Wed May 11 18:11:47 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 18:11:47 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
Message-ID: <PwjWwoTyxmUgpiqG2-7TYM_2IHuK6VexETlXoR5NarU=.4503a0c4-4b75-428d-b85f-f0465fbce877@github.com>

On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`?
>> 
>> With this change the build now passes (tested both with bundled and system zlib variants).
>> 
>> tier1, tier2 and tier3 testing has been done and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - copyright years
>  - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib
>  - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file
>  - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code

Looks good to me.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8651

From ihse at openjdk.java.net  Wed May 11 18:11:48 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 18:11:48 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <Ift_rcraR8e0IeaIz_GPSyo_41bMmqpSdCZqshJ_cGs=.fa1f6941-92cf-4315-96bb-ce57c7004ac2@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
 <Ift_rcraR8e0IeaIz_GPSyo_41bMmqpSdCZqshJ_cGs=.fa1f6941-92cf-4315-96bb-ce57c7004ac2@github.com>
Message-ID: <rCy8Zto3s4h3jSXgxCQAO_w1tXsXY0ObzyY8N77M8vo=.649ce215-9968-4f78-889e-c7236e15a8ef@github.com>

On Wed, 11 May 2022 15:03:56 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - copyright years
>>  - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib
>>  - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file
>>  - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code
>
> make/autoconf/lib-bundled.m4 line 220:
> 
>> 218:   if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then
>> 219:     LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib"
>> 220:     if test "x$OPENJDK_TARGET_OS" = xmacosx; then
> 
> Please add a comment here as to why we are doing this

@LanceAndersen Is that really needed? We normally don't comment on the reason why certain code needs certain defines. We tried to document some compiler flags in the beginning, but it turned out that most command lines ended up as essays, and this were not helpful. I think it's quite obvious what this code does: libz requires the define HAVE_UNISTD_H on macOS. I'm not even sure how you'd formulate a "why" -- "otherwise it does not work properly"?

> make/modules/java.base/lib/CoreLibraries.gmk line 139:
> 
>> 137:     DISABLED_WARNINGS_gcc := unused-function implicit-fallthrough, \
>> 138:     DISABLED_WARNINGS_clang := format-nonliteral, \
>> 139:     LDFLAGS := $(LDFLAGS_JDKLIB) \
> 
> A comment would be good here also as to the reasoning

And once again, we never comment on why we disable warnings. The context is clear enough -- there is a compiler warning that is not applicable to this module. Especially for 3rd party code, which is not nearly as stringent as we are about enabling warnings.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8651

From alanb at openjdk.java.net  Wed May 11 18:12:53 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 18:12:53 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <nJ3YUlzlAvMknJJxLkByfKxWQJ-2vYUFhJhC4DRyrCY=.9e4b5a6b-69cd-4792-89dc-94b3b1664d99@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
 <nJ3YUlzlAvMknJJxLkByfKxWQJ-2vYUFhJhC4DRyrCY=.9e4b5a6b-69cd-4792-89dc-94b3b1664d99@github.com>
Message-ID: <_-q4dXADJO6xSX8M9-NhCN7WcPzea67b7Dr6VTru5Ug=.f06265df-c88e-40ab-8955-dfdf00157dab@github.com>

On Wed, 11 May 2022 02:43:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
>> 
>> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
>> 
>> I also cleaned up related code in the JDK and HotSpot.
>> 
>> Testing:
>> - Passed tiers 1 and 2
>> - Tiers 3, 4, 5 are in progress
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8622

From alanb at openjdk.java.net  Wed May 11 19:10:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 19:10:45 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
Message-ID: <FVhsC0KYqrXqSWOt69MdFgvJZjIgrMc2LTVGsam2aDY=.1c3e2519-be3e-462d-a6a0-627e45c02c12@github.com>

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyrights
>   Fixed cast style to add a space after cast, (where consistent with file style)
>   Improved code per review comments in PollSelectors.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From prr at openjdk.java.net  Wed May 11 19:14:03 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 11 May 2022 19:14:03 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
 <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
Message-ID: <K1rvr4pekoOqk0CX5AKpq3F61FANUJlquDwtmZ3BGbQ=.6a57b5dc-73ad-4206-b9d7-52c9e695b02f@github.com>

On Wed, 11 May 2022 13:35:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid pragma error in before GCC 12
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462:
> 
>> 460:    HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing
>> 461:    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \
>> 462:         maybe-uninitialized class-memaccess unused-result extra use-after-free
> 
> Globally disabling use-after-free warnings for this package seems really
> questionable. If these are problems in the code, just suppressing the warning
> and leaving the problems to bite us seems like a bad idea.  And the problems
> ought to be reported upstream to the HarfBuzz folks.

I don't understand what the actual warning is getting at .. can anyone explain it ?

FWIW the code is still the same in upstream harfbuzz
https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From psandoz at openjdk.java.net  Wed May 11 19:18:00 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 11 May 2022 19:18:00 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v12]
In-Reply-To: <PP7oByBGJce2DZZTe_1W4dtmld2cYUyBj-MiJEo0E58=.904b7b82-0333-4520-918b-0314f0e8fa3a@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
 <PP7oByBGJce2DZZTe_1W4dtmld2cYUyBj-MiJEo0E58=.904b7b82-0333-4520-918b-0314f0e8fa3a@github.com>
Message-ID: <ZFANL7pkofW0OIXkid_UNGGBNw3NUD-IdEknprhYGxQ=.d6359adf-bdad-4272-9430-e7dcbbdaa6d4@github.com>

On Tue, 10 May 2022 14:46:56 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
>> 
>> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
>> 
>> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
>> 
>> 
>> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
>> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
>> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
>> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
>> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
>> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
>> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
>> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
>> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
>> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
>> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
>> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
>> 
>> 
>> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
>> 
>> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf
>
> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Fix overlapping registers
>  - Actually fix h when hashcode is vectorized
>  - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
>  - Fix h when vectorized for Arrays.hashCode
>  - Add missing check for AryHashCode node
>  - Fix some merge conflicts
>  - Disable Arrays.hashCode intrinsic by default for CI
>  - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
>  - Some small refactoring: store power_of_31_backwards in the code directly, compact code, and more
>  - {wip} Generalize string hashcode to Arrays.hashCode
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...29dab16b

Looks like you are making great progress.

Have you thought about ways the intrinsic implementation might be simplified if some code is retained in Java and passed as constant arguments? e.g. table of constants, scalar loop, bounds checks etc, such that the intrinsic primarily focuses on the vectorized code. To some extent that's related to John's point on generalization, and through simplification there may be some generalization.

For example if there was a general intrinsic that returned a long value (e.g. first 32 bits are the offset in the array to continue processing, the second 32 bits are the current hashcode value) then we could call that from the Java implementations that then proceed with the scalar loop up to the array length. The Java implementation intrinsic would return `(0L | 1L << 32)`.

Separately it would be nice to consider computing the hash code from the contents of a memory segment, similar to how we added `mismatch` support, but the trick of returning a value that merges the offset and hash code would not work, unless we guarantee that the remaining elements to process is always less than a certain value.

The `long[]` hashcode is annoying given `(element ^ (element >>> 32))`, but if we simplify the intrinsic maybe we can add back that complexity?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7700

From lancea at openjdk.java.net  Wed May 11 19:18:49 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 11 May 2022 19:18:49 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <Ift_rcraR8e0IeaIz_GPSyo_41bMmqpSdCZqshJ_cGs=.fa1f6941-92cf-4315-96bb-ce57c7004ac2@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
 <Ift_rcraR8e0IeaIz_GPSyo_41bMmqpSdCZqshJ_cGs=.fa1f6941-92cf-4315-96bb-ce57c7004ac2@github.com>
Message-ID: <8P-ZnuJlg11CfrjiE1H5TBXSO90Yc720GVglwIEO3oU=.de7c3c64-6fb9-4eb3-9753-c608732ebcaa@github.com>

On Wed, 11 May 2022 15:03:56 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - copyright years
>>  - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib
>>  - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file
>>  - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code
>
> make/autoconf/lib-bundled.m4 line 220:
> 
>> 218:   if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then
>> 219:     LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib"
>> 220:     if test "x$OPENJDK_TARGET_OS" = xmacosx; then
> 
> Please add a comment here as to why we are doing this

> @LanceAndersen Is that really needed? We normally don't comment on the reason why certain code needs certain defines. We tried to document some compiler flags in the beginning, but it turned out that most command lines ended up as essays, and this were not helpful. I think it's quite obvious what this code does: libz requires the define HAVE_UNISTD_H on macOS. I'm not even sure how you'd formulate a "why" -- "otherwise it does not work properly"?

The  zlib configure script, which needs to be run prior  running make to build the upstream repository, will determine if HAVE_UNISTD_H is needed and generate zconf.h replacing the macro with "1".    My reason for adding a comment as this is a variant from how zlib is built upstream.  Perhaps just updating open/src/java.base/share/native/libzip/zlib/ChangeLog  is enough.  I was just trying to document why we are doing this.


Another question would it make sense to set LIBZ_DISABLED_WARNINGS_CLANG in make/autoconf/lib-bundled.m4 so that the value in the case of zlib is set in one location?  In addition, I  can log a request to address this in the upstream project so we do not need to worry about this warning going forward.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8651

From joehw at openjdk.java.net  Wed May 11 19:20:55 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 11 May 2022 19:20:55 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v4]
In-Reply-To: <1zSZc32pEuDhOtIfc1t1svegXZ_Ty3cUVSBnQkWpIDA=.ef77de25-0da2-4ca0-85a3-4449c46ad870@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <1zSZc32pEuDhOtIfc1t1svegXZ_Ty3cUVSBnQkWpIDA=.ef77de25-0da2-4ca0-85a3-4449c46ad870@github.com>
Message-ID: <b3b_8JxXZ7g64A-w2hsON22ZQ6hxPTCuta-Tz0GD31o=.e6b729f3-021b-4d21-9a63-7ded345a1906@github.com>

On Wed, 11 May 2022 17:04:41 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixup

src/java.base/share/classes/java/util/TimeZone.java line 80:

> 78:  *         {@code GMT} <i>Sign</i> <i>Hours</i> {@code :} <i>Minutes</i> {@code :} <i>Seconds</i>
> 79:  *         {@code GMT} <i>Sign</i> <i>Hours</i> {@code :} <i>Minutes</i>
> 80:  *         {@code GMT} <i>Sign</i> <i>Hours</i> <i>Minutes</i>

For hours and minutes, the format can be hh:mm or hhmm. Is it worth it to support hhmmss as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From lancea at openjdk.java.net  Wed May 11 19:23:50 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 11 May 2022 19:23:50 GMT
Subject: RFR: 8286594: (zipfs) Improvements after JDK-8251329
In-Reply-To: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com>
References: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com>
Message-ID: <-CY8VrgET0umvXMyeB9s7y_b9qsON3_mTD5IDtHiuyU=.aeeb6720-a674-42c5-bd6a-be864d9e2021@github.com>

On Wed, 11 May 2022 15:32:38 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements.
> 
> It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode::nameAsString to return the node name as a String.

Looks good Christoph.  Thank you for separating this out from the other PR

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8655

From iklam at openjdk.java.net  Wed May 11 19:29:57 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 19:29:57 GMT
Subject: RFR: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <fJVbOoDRaDA37EScdewg0G4nCyTzYZ2M4ZXWY_ubpoQ=.1be2132e-0af9-4a36-a9ee-33cc182f745d@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
 <fJVbOoDRaDA37EScdewg0G4nCyTzYZ2M4ZXWY_ubpoQ=.1be2132e-0af9-4a36-a9ee-33cc182f745d@github.com>
Message-ID: <LvpF1pmJ9MSZD7OYitX5Q_jy2uJSNG1cUZWY3KywhyU=.8080bd6b-2b9d-4992-81cf-39d8ed158cf9@github.com>

On Tue, 10 May 2022 20:03:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
>> 
>> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
>> 
>> I also cleaned up related code in the JDK and HotSpot.
>> 
>> Testing:
>> - Passed tiers 1 ~ 5
>
> I skimmed through the changes and I think they look okay. In the distant past there were tools outside of the JDK that used the jvmstat API directly. It's possible that VisualVM still does but it would only compile/run if --add-exports is used to export the sun.jvmstat.* packages. So it might be that dropping the parameter from a method in RemoteHost is noticed and I think that is okay because this package is not exported and is not meant to be used by code outside of the JDK.

Thanks to @AlanBateman and @cl4es for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8622

From iklam at openjdk.java.net  Wed May 11 19:29:59 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 19:29:59 GMT
Subject: Integrated: 8286441: Remove mode parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
References: <v4jlLM5QuBflwl2OztKHBEscTqbTKarmP6sp2W2322o=.f216f27a-38fd-4296-8f18-3a45f60ed052@github.com>
Message-ID: <c5o6SCVcv3i5y1sOxqKYcrktFjB-Wwxr4Fzj8xwIULs=.3f841139-5230-4357-b88c-568e93e453fe@github.com>

On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified.
> 
> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode.
> 
> I also cleaned up related code in the JDK and HotSpot.
> 
> Testing:
> - Passed tiers 1 ~ 5

This pull request has now been integrated.

Changeset: fcf49f42
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fcf49f42cef4ac3e50b3b480aecf6fa38cf5be00
Stats:     205 lines in 15 files changed: 3 ins; 153 del; 49 mod

8286441: Remove mode parameter from jdk.internal.perf.Perf.attach()

Reviewed-by: redestad, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8622

From psandoz at openjdk.java.net  Wed May 11 19:49:47 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 11 May 2022 19:49:47 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
Message-ID: <P3jW_5XRZQBmYrG71DRds1UC2LlG87EzDkQ3NB9Xh48=.25df21b3-bb06-4c45-ad81-21f2cfd25e93@github.com>

On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename "use_predicate" to "needs_predicate"

I tried your test code with the patch and logged compilation (`-XX:-TieredCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:+PrintIntrinsics -Xbatch`)

For `func` the first call to `VectorSupport::loadMasked` is intrinsic and inlined:

    @ 45   jdk.internal.vm.vector.VectorSupport::loadMasked (40 bytes)   (intrinsic)

But the second call (for the last loop iteration) fails to inline: 

    @ 45   jdk.internal.vm.vector.VectorSupport::loadMasked (40 bytes)   failed to inline (intrinsic)


Since i am running on an mac book this looks right and aligns with the `-XX:+PrintIntrinsics` output: 

  ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
  ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
  ** not supported: op=loadMasked vlen=8 etype=int using_byte_array=0

?

I have not looked at the code gen nor measured performance comparing the case when never out of bounds and only out of bounds for the last loop iteration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From naoto at openjdk.java.net  Wed May 11 20:04:39 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 20:04:39 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v5]
In-Reply-To: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
Message-ID: <oTlybq8AJdxvKe0UvRddrE-n90BdGoYsbHGdWl8Ynps=.d43bf335-dffb-4afe-a70a-10bc21d01fe3@github.com>

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

Naoto Sato 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 six additional commits since the last revision:

 - Disallow `UTC` -> `GMT`
 - Merge branch 'master' into JDK-8285844
 - Minor fixup
 - Allowed round-trips for offset-style ZoneIds.
 - Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
 - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/9722decd..11150ac5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=03-04

  Stats: 8626 lines in 248 files changed: 4866 ins; 2323 del; 1437 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Wed May 11 20:04:40 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 20:04:40 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v4]
In-Reply-To: <b3b_8JxXZ7g64A-w2hsON22ZQ6hxPTCuta-Tz0GD31o=.e6b729f3-021b-4d21-9a63-7ded345a1906@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <1zSZc32pEuDhOtIfc1t1svegXZ_Ty3cUVSBnQkWpIDA=.ef77de25-0da2-4ca0-85a3-4449c46ad870@github.com>
 <b3b_8JxXZ7g64A-w2hsON22ZQ6hxPTCuta-Tz0GD31o=.e6b729f3-021b-4d21-9a63-7ded345a1906@github.com>
Message-ID: <P36FRe2jbszUPmzbMtjw8qG1-fADlhKRxBNXLbcpPDM=.4f063f85-2901-4cf3-bff1-ceda16051a12@github.com>

On Wed, 11 May 2022 18:30:32 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixup
>
> src/java.base/share/classes/java/util/TimeZone.java line 80:
> 
>> 78:  *         {@code GMT} <i>Sign</i> <i>Hours</i> {@code :} <i>Minutes</i> {@code :} <i>Seconds</i>
>> 79:  *         {@code GMT} <i>Sign</i> <i>Hours</i> {@code :} <i>Minutes</i>
>> 80:  *         {@code GMT} <i>Sign</i> <i>Hours</i> <i>Minutes</i>
> 
> For hours and minutes, the format can be hh:mm or hhmm. Is it worth it to support hhmmss as well?

It would be consistent, but I don't see much requirement for it. I'll consider if someone needs it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From scolebourne at openjdk.java.net  Wed May 11 20:21:43 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 11 May 2022 20:21:43 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v5]
In-Reply-To: <oTlybq8AJdxvKe0UvRddrE-n90BdGoYsbHGdWl8Ynps=.d43bf335-dffb-4afe-a70a-10bc21d01fe3@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <oTlybq8AJdxvKe0UvRddrE-n90BdGoYsbHGdWl8Ynps=.d43bf335-dffb-4afe-a70a-10bc21d01fe3@github.com>
Message-ID: <d8gqOIk8sB_sG3F25ZSQALDCjaoOBu45ilWr5KD9Hek=.24953931-ea90-4f9f-a37d-4aedb1ad352e@github.com>

On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.
>
> Naoto Sato 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 six additional commits since the last revision:
> 
>  - Disallow `UTC` -> `GMT`
>  - Merge branch 'master' into JDK-8285844
>  - Minor fixup
>  - Allowed round-trips for offset-style ZoneIds.
>  - Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
>  - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

Marked as reviewed by scolebourne (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From pchilanomate at openjdk.java.net  Wed May 11 20:31:05 2022
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 11 May 2022 20:31:05 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <AIN9VRXcDj-YKtSkychFW7_ZqXdx3AsWmeMnvzJchl8=.680b9133-929d-4a47-809a-2a654a94bf26@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
 <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
 <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>
 <T73dHwsxmGWzDhJzzaLzEkOpsi6LB7jHBwcBI-JTJlY=.3929d080-0ae2-4645-88db-f5dfa8f0e855@github.com>
 <AIN9VRXcDj-YKtSkychFW7_ZqXdx3AsWmeMnvzJchl8=.680b9133-929d-4a47-809a-2a654a94bf26@github.com>
Message-ID: <WCNDNQabM_3gZBaog255y0LSokj044con0d23ZeQ7hA=.cfae3ed7-b420-47fc-bf73-f7f65cddf385@github.com>

On Wed, 11 May 2022 17:55:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Oh nice! I was just thinking that the only possible way out of this conundrum would be to somehow block the delivery of async exceptions (at least outside of the user's exception handler). So, that seems to be exactly what we need :)
>
> I went ahead and implemented this suggestion. Now we block async exceptions in on_entry, and unblock in on_exit.

Is it possible for these upcalls to be nested? If yes, we could add a boolean to context to avoid unsetting the flag in those nested cases. And now that I think we should probably add that check in NoAsyncExceptionDeliveryMark too if we allow broader use of this flag. David added the NoAsyncExceptionDeliveryMark code with that assert about nesting so maybe he might have more insights about that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From joehw at openjdk.java.net  Wed May 11 20:42:52 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 11 May 2022 20:42:52 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v5]
In-Reply-To: <oTlybq8AJdxvKe0UvRddrE-n90BdGoYsbHGdWl8Ynps=.d43bf335-dffb-4afe-a70a-10bc21d01fe3@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <oTlybq8AJdxvKe0UvRddrE-n90BdGoYsbHGdWl8Ynps=.d43bf335-dffb-4afe-a70a-10bc21d01fe3@github.com>
Message-ID: <UlHNWrfwhbmgqDbdXUN1Mki95pmgJyLM_J6xVjCwS8k=.359cc2aa-2c42-4ea4-afd4-adca611c1f81@github.com>

On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.
>
> Naoto Sato 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 six additional commits since the last revision:
> 
>  - Disallow `UTC` -> `GMT`
>  - Merge branch 'master' into JDK-8285844
>  - Minor fixup
>  - Allowed round-trips for offset-style ZoneIds.
>  - Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
>  - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From darcy at openjdk.java.net  Wed May 11 20:47:12 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 11 May 2022 20:47:12 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec
Message-ID: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>

While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.

The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.

Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605

-------------

Commit messages:
 - JDK-8286604: Update InputStream and OutputStream to use @implSpec

Changes: https://git.openjdk.java.net/jdk/pull/8663/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8663&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286604
  Stats: 36 lines in 2 files changed: 18 ins; 4 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8663/head:pull/8663

PR: https://git.openjdk.java.net/jdk/pull/8663

From uschindler at openjdk.java.net  Wed May 11 20:48:55 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 11 May 2022 20:48:55 GMT
Subject: RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for
 all ZoneOffsets and returns GMT unexpected [v5]
In-Reply-To: <oTlybq8AJdxvKe0UvRddrE-n90BdGoYsbHGdWl8Ynps=.d43bf335-dffb-4afe-a70a-10bc21d01fe3@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
 <oTlybq8AJdxvKe0UvRddrE-n90BdGoYsbHGdWl8Ynps=.d43bf335-dffb-4afe-a70a-10bc21d01fe3@github.com>
Message-ID: <VW6x2gXnDv_K3yT7XWgsLxRkm7us_nKRrAcI5GzJk1w=.ae3c1152-c0db-440a-bba8-f937b4bfb8cb@github.com>

On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.
>
> Naoto Sato 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 six additional commits since the last revision:
> 
>  - Disallow `UTC` -> `GMT`
>  - Merge branch 'master' into JDK-8285844
>  - Minor fixup
>  - Allowed round-trips for offset-style ZoneIds.
>  - Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
>  - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

Marked as reviewed by uschindler (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From bpb at openjdk.java.net  Wed May 11 20:57:19 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 11 May 2022 20:57:19 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off, 0) returns -1 at EOF
Message-ID: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>

Modify the specification of `SequenceInputStream.read(byte[],int,int)` to indicate that `-1` is returned at the EOF of the last stream even if `len` is zero.

-------------

Commit messages:
 - 8286200: SequenceInputStream::read(b, off, 0) returns -1 at EOF

Changes: https://git.openjdk.java.net/jdk/pull/8664/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8664&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286200
  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8664.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8664/head:pull/8664

PR: https://git.openjdk.java.net/jdk/pull/8664

From bpb at openjdk.java.net  Wed May 11 20:57:19 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 11 May 2022 20:57:19 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF
In-Reply-To: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
Message-ID: <Tl6IDUg8vg5Zx_w1heOv9LYgeR36odUhqYZF6L213Y4=.69f57e50-164d-493a-bcd4-b228415d8b03@github.com>

On Wed, 11 May 2022 20:47:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the specification of `SequenceInputStream.read(byte[],int,int)` to indicate that `-1` is returned at the EOF of the last stream even if `len` is zero.

The `InputStream.read(byte[],int,int)` specification indicates


If len is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt
to read at least one byte. If no byte is available because the stream is at end of file,
the value -1 is returned; otherwise, at least one byte is read and stored into b.


so that zero should be returned if `len` is zero regardless of anything else. `SequenceInputStream` does not follow this so its specification should be modified to document the existing, longstanding behavior.

A CSR will be filed once there is consensus here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8664

From bpb at openjdk.java.net  Wed May 11 20:59:53 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 11 May 2022 20:59:53 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec
In-Reply-To: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
Message-ID: <c8y0jQsTQlLS6Y1MSGvrFPn8O6Ie7nAuPLKgnuI2BcA=.26fcbb62-48dc-48d3-b697-a6f30c87bacf@github.com>

On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.
> 
> The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8663

From lancea at openjdk.java.net  Wed May 11 21:03:47 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 11 May 2022 21:03:47 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec
In-Reply-To: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
Message-ID: <AmMoF0UW_orKrkoQf6Wi5R9Pys0PNRDRaWpQz8Ee-gg=.e32c0946-4338-4dcc-8b4e-902237c58092@github.com>

On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.
> 
> The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8663

From iris at openjdk.java.net  Wed May 11 21:19:49 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 11 May 2022 21:19:49 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec
In-Reply-To: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
Message-ID: <gqaeXWHwgO2QDYw3t6fGlbPB5QZEwppzVuaErKpGyvc=.00c6fdc6-3049-48a4-aa32-9096dbfdcc86@github.com>

On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.
> 
> The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605

Associated CSR also reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8663

From mandy.chung at oracle.com  Wed May 11 21:29:25 2022
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 May 2022 14:29:25 -0700
Subject: Unused method sun.reflect.misc.MethodUtil.getPublicMethods
In-Reply-To: <CAF+DQ5fduaH1pwur2Ph=LSVD7fHDTruz9CBc-wOmnkz5nNeHcw@mail.gmail.com>
References: <CAF+DQ5fduaH1pwur2Ph=LSVD7fHDTruz9CBc-wOmnkz5nNeHcw@mail.gmail.com>
Message-ID: <89648b4b-af61-89fe-d111-f2f0faf420ef@oracle.com>

They are unused and leftover since JDK 7. It's good to remove them.

Thanks
Mandy

On 4/30/22 7:48 AM, Andrey Turbanov wrote:
> Hello.
> I found a few methods in MethodUtil class which seem unused to me:
> getPublicMethods, getInterfaceMethods, getInternalPublicMethods ,addMethod.
>
> Are they somehow used by VM, or is it just leftovers from some refactorings?
> I wonder if we can drop them.
>
>
> Andrey Turbanov

From almatvee at openjdk.java.net  Wed May 11 21:39:26 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 11 May 2022 21:39:26 GMT
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store due
 to info.plist embedded in java exe
Message-ID: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>

- It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.
 - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles.
 - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error.
 - Added two tests to validate fix.

-------------

Commit messages:
 - 8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

Changes: https://git.openjdk.java.net/jdk/pull/8666/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8666&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286122
  Stats: 223 lines in 7 files changed: 217 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8666.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8666/head:pull/8666

PR: https://git.openjdk.java.net/jdk/pull/8666

From asemenyuk at openjdk.java.net  Wed May 11 21:58:46 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 11 May 2022 21:58:46 GMT
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
Message-ID: <eqx56jaVRiVa1qPzXVxzYPICRZnQcbLW0Ma6VlWcEwU=.7e38d56c-93b9-44cb-abcf-26d2d36e14eb@github.com>

On Wed, 11 May 2022 21:31:44 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.
>  - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles.
>  - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error.
>  - Added two tests to validate fix.

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/macosx/MacAppStoreRuntimeTest.java line 102:

> 100: 
> 101:         cmd.execute(1);
> 102:     }

@Test
@Parameter("true")
@Parameter("false")
public static void test(boolean stripNativeCommands) throws Exception {
    JPackageCommand cmd = JPackageCommand.helloAppImage();
    cmd.addArguments("--mac-app-store", "--runtime-image", getRuntimeImage(stripNativeCommands));

    if (stripNativeCommands) {
        cmd.executeAndAssertHelloAppImageCreated();
    } else {
        cmd.execute(1);
    }
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/8666

From asemenyuk at openjdk.java.net  Wed May 11 22:01:58 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 11 May 2022 22:01:58 GMT
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
Message-ID: <YGkae8ZT4Kxe5dpcPQtUuBxYdT43TlcE3sDz9tlWLEM=.be671d51-56a7-4533-94b9-7b47a1cfa828@github.com>

On Wed, 11 May 2022 21:31:44 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.
>  - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles.
>  - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error.
>  - Added two tests to validate fix.

test/jdk/tools/jpackage/macosx/MacAppStoreJlinkOptionsTest.java line 48:

> 46: 
> 47:     @Test
> 48:     public static void test() throws Exception {

I'd give some more descriptive names to test functions than `test` and `test2`. Something like `testWithStripNativeCommands` and `testWithoutStripNativeCommands` maybe?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8666

From ihse at openjdk.java.net  Wed May 11 22:06:55 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 11 May 2022 22:06:55 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <8P-ZnuJlg11CfrjiE1H5TBXSO90Yc720GVglwIEO3oU=.de7c3c64-6fb9-4eb3-9753-c608732ebcaa@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
 <Ift_rcraR8e0IeaIz_GPSyo_41bMmqpSdCZqshJ_cGs=.fa1f6941-92cf-4315-96bb-ce57c7004ac2@github.com>
 <8P-ZnuJlg11CfrjiE1H5TBXSO90Yc720GVglwIEO3oU=.de7c3c64-6fb9-4eb3-9753-c608732ebcaa@github.com>
Message-ID: <j6IccZAZS1NU6pQlS40nGESdzkjlCIMOhTTNCV6uNL0=.e52744ed-5d08-481d-88de-3200bcc9fcb9@github.com>

On Wed, 11 May 2022 19:14:54 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> make/autoconf/lib-bundled.m4 line 220:
>> 
>>> 218:   if test "x$USE_EXTERNAL_LIBZ" = "xfalse"; then
>>> 219:     LIBZ_CFLAGS="$LIBZ_CFLAGS -I$TOPDIR/src/java.base/share/native/libzip/zlib"
>>> 220:     if test "x$OPENJDK_TARGET_OS" = xmacosx; then
>> 
>> Please add a comment here as to why we are doing this
>
>> @LanceAndersen Is that really needed? We normally don't comment on the reason why certain code needs certain defines. We tried to document some compiler flags in the beginning, but it turned out that most command lines ended up as essays, and this were not helpful. I think it's quite obvious what this code does: libz requires the define HAVE_UNISTD_H on macOS. I'm not even sure how you'd formulate a "why" -- "otherwise it does not work properly"?
> 
> The  zlib configure script, which needs to be run prior  running make to build the upstream repository, will determine if HAVE_UNISTD_H is needed and generate zconf.h replacing the macro with "1".    My reason for adding a comment as this is a variant from how zlib is built upstream.  Perhaps just updating open/src/java.base/share/native/libzip/zlib/ChangeLog  is enough.  I was just trying to document why we are doing this.
> 
> 
> Another question would it make sense to set LIBZ_DISABLED_WARNINGS_CLANG in make/autoconf/lib-bundled.m4 so that the value in the case of zlib is set in one location?  In addition, I  can log a request to address this in the upstream project so we do not need to worry about this warning going forward.

It would not make sense to set the disabled warning in the configure script, no. The current code looks perfectly fine. Disabled warnings per module are set in the makefiles.

If you feel strongly that this needs to be documented more than in the JBS issue and this PR review, updating the zlib ChangeLog file is probably the way to go. I have no strong opinion on that. But from the build system PoV, the current code is fine as it is to be committed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8651

From mik3hall at gmail.com  Wed May 11 22:17:41 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 11 May 2022 17:17:41 -0500
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
Message-ID: <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>

Is this restricted somehow to Mac App Store applications?

Is a warning issued as stripping native commands  may break application functionality?

Is it not possible for the user to provide their own Info.plist with  a different bundle identifier that doesn?t collide?

I?m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?

From mik3hall at gmail.com  Wed May 11 22:20:21 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 11 May 2022 17:20:21 -0500
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
Message-ID: <533450DD-E77B-4813-94BF-739E0A4B207E@gmail.com>



> On May 11, 2022, at 5:17 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> I?m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?

Or just change it in the current build so it doesn?t collide? With the application or whatever one it is colliding with.


From lancea at openjdk.java.net  Wed May 11 22:25:03 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 11 May 2022 22:25:03 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
Message-ID: <7v43S0cpiMtx_4IQPS8ERo-ynpc-V5Q7_kDAGYzB78g=.f691bf42-60e3-42c4-93a0-dcba5079574a@github.com>

On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`?
>> 
>> With this change the build now passes (tested both with bundled and system zlib variants).
>> 
>> tier1, tier2 and tier3 testing has been done and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - copyright years
>  - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib
>  - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file
>  - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code

Thanks Jai for the latest tweaks to the our original patch.

I think we should be good to go

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8651

From lancea at openjdk.java.net  Wed May 11 22:25:05 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 11 May 2022 22:25:05 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <j6IccZAZS1NU6pQlS40nGESdzkjlCIMOhTTNCV6uNL0=.e52744ed-5d08-481d-88de-3200bcc9fcb9@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
 <Ift_rcraR8e0IeaIz_GPSyo_41bMmqpSdCZqshJ_cGs=.fa1f6941-92cf-4315-96bb-ce57c7004ac2@github.com>
 <8P-ZnuJlg11CfrjiE1H5TBXSO90Yc720GVglwIEO3oU=.de7c3c64-6fb9-4eb3-9753-c608732ebcaa@github.com>
 <j6IccZAZS1NU6pQlS40nGESdzkjlCIMOhTTNCV6uNL0=.e52744ed-5d08-481d-88de-3200bcc9fcb9@github.com>
Message-ID: <YIchcCljXJqy7EAyji1bbDwGPd35ZBcn7am3kqPLXzM=.068ef154-4090-46de-8c3a-ff52dda8bae6@github.com>

On Wed, 11 May 2022 22:03:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> It would not make sense to set the disabled warning in the configure script, no. The current code looks perfectly fine. Disabled warnings per module are set in the makefiles.

OK, that you for your feedback regarding the makefile changes vs. configure script. 
> 
> If you feel strongly that this needs to be documented more than in the JBS issue and this PR review, updating the zlib ChangeLog file is probably the way to go. I have no strong opinion on that. But from the build system PoV, the current code is fine as it is to be committed.


OK, I am probably overthinking the need to document this

-------------

PR: https://git.openjdk.java.net/jdk/pull/8651

From duke at openjdk.java.net  Wed May 11 22:47:48 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 11 May 2022 22:47:48 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec
In-Reply-To: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
Message-ID: <q1cnGl_ulTmktyFm3kDjgtzHb9wI1pgWovogZsaF6co=.8f872b3a-d0d6-47de-a3ed-633f53a461e4@github.com>

On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.
> 
> The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605

src/java.base/share/classes/java/io/OutputStream.java line 151:

> 149:      * The {@code write} method of {@code OutputStream} calls
> 150:      * the write method of one argument on each of the bytes to be
> 151:      * written out. Subclasses are encouraged to override this method and

Shouldn't the "subclasses" information be part of the API Note?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8663

From iklam at openjdk.java.net  Wed May 11 23:29:12 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 11 May 2022 23:29:12 GMT
Subject: RFR: 8286560: Remove user parameter from
 jdk.internal.perf.Perf.attach()
Message-ID: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>

The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed.

-------------

Commit messages:
 - more cleanup
 - 8286560: Remove user parameter from jdk.internal.perf.Perf.attach()

Changes: https://git.openjdk.java.net/jdk/pull/8669/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8669&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286560
  Stats: 120 lines in 5 files changed: 2 ins; 95 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8669.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8669/head:pull/8669

PR: https://git.openjdk.java.net/jdk/pull/8669

From darcy at openjdk.java.net  Thu May 12 00:16:17 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 12 May 2022 00:16:17 GMT
Subject: RFR: JDK-8286615: Small refactor to SerializedLambda
Message-ID: <wpYuGehq7x3d8YRH0ja0_JRfNZy1ihXW3yldLUx5ZQc=.af897cbf-e942-4631-a6e9-37c73351a3cb@github.com>

Noticed by inspection during a CSR review, small refactoring to use a message-cause exception constructor when one is available.

Will update the copyright before a push.

-------------

Commit messages:
 - JDK-8286615: Small refactor to SerializedLambda

Changes: https://git.openjdk.java.net/jdk/pull/8670/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8670&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286615
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8670.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8670/head:pull/8670

PR: https://git.openjdk.java.net/jdk/pull/8670

From ysuenaga at openjdk.java.net  Thu May 12 00:29:47 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 12 May 2022 00:29:47 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <K1rvr4pekoOqk0CX5AKpq3F61FANUJlquDwtmZ3BGbQ=.6a57b5dc-73ad-4206-b9d7-52c9e695b02f@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
 <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
 <K1rvr4pekoOqk0CX5AKpq3F61FANUJlquDwtmZ3BGbQ=.6a57b5dc-73ad-4206-b9d7-52c9e695b02f@github.com>
Message-ID: <PAHnhQmFdvqr4WpEEmWHOc2exFIeX6zxHCQQs72eJ50=.5430fb2e-e5a8-4fec-8f2b-ab47fd7caf51@github.com>

On Wed, 11 May 2022 19:11:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462:
>> 
>>> 460:    HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing
>>> 461:    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \
>>> 462:         maybe-uninitialized class-memaccess unused-result extra use-after-free
>> 
>> Globally disabling use-after-free warnings for this package seems really
>> questionable. If these are problems in the code, just suppressing the warning
>> and leaving the problems to bite us seems like a bad idea.  And the problems
>> ought to be reported upstream to the HarfBuzz folks.
>
> I don't understand what the actual warning is getting at .. can anyone explain it ?
> 
> FWIW the code is still the same in upstream harfbuzz
> https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc

I've pasted a part of warning messages to description of this PR, all of messages are here:


In function 'void trampoline_reference(hb_trampoline_closure_t*)',
    inlined from 'void hb_font_funcs_set_glyph_func(hb_font_funcs_t*, hb_font_get_glyph_func_t, void*, hb_destroy_func_t)' at /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2368:24:

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From asemenyuk at openjdk.java.net  Thu May 12 00:33:00 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 12 May 2022 00:33:00 GMT
Subject: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as
 "damaged"
In-Reply-To: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
References: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
Message-ID: <OY57xUbIjQUEyoKVhe6dirHjykz6hYVQPqEgyFlJlUo=.debf2a00-6ac7-4f6b-9fb4-360df0a0511a@github.com>

On Wed, 4 May 2022 03:56:10 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - No changes to code provided by original fix.
>  - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute unsigned code and code should be at least ad hoc signed.
>  - Signing of app bundle produced by AppContentTest.java fails, since it has invalid app bundle structure with added files into Content folder. Thus test is executed but failure is always expected on macOS aarch64.

test/jdk/tools/jpackage/macosx/SigningAppImageTest.java line 72:

> 70:     @Parameters
> 71:     public static List<Object[]> data() {
> 72:         return List.of(new Object[][] {{"true"}, {"false"}});

I'd replace use of `@Parameters` with `@Parameter` as follows:

@Test
@Parameter("true")
@Parameter("false")
public static void test(boolean doSign) {...}

-------------

PR: https://git.openjdk.java.net/jdk/pull/8527

From asemenyuk at openjdk.java.net  Thu May 12 00:37:46 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 12 May 2022 00:37:46 GMT
Subject: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as
 "damaged"
In-Reply-To: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
References: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
Message-ID: <NEia8hdDq9Qsi7krJm92Z7B_hS2QGKRTj1jCbtuqEFY=.a4a3a60b-dcc9-4e2e-9810-4298eaf5f8f5@github.com>

On Wed, 4 May 2022 03:56:10 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - No changes to code provided by original fix.
>  - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute unsigned code and code should be at least ad hoc signed.
>  - Signing of app bundle produced by AppContentTest.java fails, since it has invalid app bundle structure with added files into Content folder. Thus test is executed but failure is always expected on macOS aarch64.

Any chance logic traversing runtime and adjusting the permissions of its files in `unsignAppBundle()` and ` signAdHocAppBundle()` can be moved to a single function instead of being duplicated in both of them?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8527

From ysuenaga at openjdk.java.net  Thu May 12 00:38:34 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 12 May 2022 00:38:34 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
 <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
Message-ID: <I4Uc38fu0k2MAtPyvG9LWyVqfUuPmwSsAze3oyLeWd0=.8d1f4f87-f8c9-42af-bbbc-103f7abc95ab@github.com>

On Wed, 11 May 2022 13:35:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid pragma error in before GCC 12
>
> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 51:
> 
>> 49: 
>> 50: #define PRAGMA_STRINGOP_OVERFLOW_IGNORED \
>> 51:   PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow")
> 
> Are the reported problems with format/stringop-overflow real? Or are they
> false positives? If they are real then I'm not going to approve ignoring them,
> unless there is some urgent reason and there are followup bug reports for
> fixing them.

I think all of warnings in HotSpot are false-positives, so I added new pragmas to compilerWarnings.hpp, and use it in HotSpot code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From bpb at openjdk.java.net  Thu May 12 01:05:04 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 12 May 2022 01:05:04 GMT
Subject: RFR: JDK-8286615: Small refactor to SerializedLambda
In-Reply-To: <wpYuGehq7x3d8YRH0ja0_JRfNZy1ihXW3yldLUx5ZQc=.af897cbf-e942-4631-a6e9-37c73351a3cb@github.com>
References: <wpYuGehq7x3d8YRH0ja0_JRfNZy1ihXW3yldLUx5ZQc=.af897cbf-e942-4631-a6e9-37c73351a3cb@github.com>
Message-ID: <k2D0Dwe9Tdpg23nPsLqCyz69FC9B_qjbsz1_TZNHPmQ=.4ba6d671-835f-42e5-afe0-c3805639e5dd@github.com>

On Thu, 12 May 2022 00:10:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Noticed by inspection during a CSR review, small refactoring to use a message-cause exception constructor when one is available.
> 
> Will update the copyright before a push.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8670

From ysuenaga at openjdk.java.net  Thu May 12 01:11:39 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 12 May 2022 01:11:39 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <DR2hvyOTMElYPvyK5c920M9wq8ZEmM5Ei_6xGd1CCME=.fb936f05-ea1c-4f4f-8b91-0427a02270b1@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
 <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
 <DR2hvyOTMElYPvyK5c920M9wq8ZEmM5Ei_6xGd1CCME=.fb936f05-ea1c-4f4f-8b91-0427a02270b1@github.com>
Message-ID: <j_A3RCfLeYsYHSDxiLFYyD8ouoGTEgQUtHUDzgBr4Os=.8b74226f-d71b-44fd-955c-8df34aacd943@github.com>

On Wed, 11 May 2022 14:27:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 1629:
>> 
>>> 1627:         const char *arg = jargv[i];
>>> 1628:         if (arg[0] == '-' && arg[1] == 'J') {
>>> 1629:             *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2);
>> 
>> Wow!
>
> I wonder if the client expects NULL strings in the result, or if the NULL value should be an empty string?  If empty strings are okay, this would be simpler without the conditional, just dup from arg + 2 to the terminating byte (which might be immediate).

`NULL` affects as a loop stopper in `ParseArguments()` as following:


static jboolean
ParseArguments(int *pargc, char ***pargv,
               int *pmode, char **pwhat,
               int *pret, const char *jrepath)
{
    int argc = *pargc;
    char **argv = *pargv;
    int mode = LM_UNKNOWN;
    char *arg;

    *pret = 0;

    while ((arg = *argv) != 0 && *arg == '-') {


But I'm not sure it is valid, I think it might be discussed as another issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Thu May 12 01:17:36 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 12 May 2022 01:17:36 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v3]
In-Reply-To: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
Message-ID: <EUhWL3P1WSHOQR7AbL_JrKQKY9ybzxwhhL4nag1EKfY=.e3af7015-06d0-4582-b4fa-b7ef625ebd65@github.com>

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
> 
> * -Wstringop-overflow
>     * src/hotspot/share/oops/array.hpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
> 
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Use return value from JLI_Snprintf

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8646/files
  - new: https://git.openjdk.java.net/jdk/pull/8646/files/7f155256..8d608414

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=01-02

  Stats: 11 lines in 1 file changed: 4 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Thu May 12 01:17:37 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 12 May 2022 01:17:37 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
 <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
Message-ID: <mGynrW5oz-gk6RK7bVQ9vigCsg7VabdIWEM6eLwB7Ts=.94816e74-eae7-40c8-9654-f3b14645ed48@github.com>

On Wed, 11 May 2022 13:43:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid pragma error in before GCC 12
>
> src/java.base/unix/native/libjli/java_md_common.c line 135:
> 
>> 133:     if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0;
>> 134:     JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd);
>> 135: #pragma GCC diagnostic pop
> 
> Wouldn't it be better to just call JLI_Snprintf without the precheck and check the result to determine whether it was successful or was truncated?  I think that kind of check is supposed to make gcc's truncation checker happy.

The warning has gone when using return value from `JLI_Snprintf()` in new commit!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Thu May 12 01:27:30 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 12 May 2022 01:27:30 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4]
In-Reply-To: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
Message-ID: <hRz0_TToYgAPiC2722w2E0YzZztTp34v74R4OM6A78k=.f5ae0319-cd63-421a-b416-652757587567@github.com>

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
> 
> * -Wstringop-overflow
>     * src/hotspot/share/oops/array.hpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
> 
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Calculate char offset before realloc()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8646/files
  - new: https://git.openjdk.java.net/jdk/pull/8646/files/8d608414..b3afa3e0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=02-03

  Stats: 18 lines in 1 file changed: 3 ins; 14 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Thu May 12 01:27:30 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 12 May 2022 01:27:30 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
 <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
Message-ID: <Rly38Ik0zMtyfcQic858KAk03tfiKXgSkul6P3k31yQ=.7694f740-f25f-4b2e-824c-ff46cc27b088@github.com>

On Wed, 11 May 2022 13:47:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid pragma error in before GCC 12
>
> src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c line 193:
> 
>> 191: #if defined(__GNUC__) && __GNUC__ >= 12
>> 192: #pragma GCC diagnostic pop
>> 193: #endif
> 
> Rather than all this warning suppression cruft and the comment explaining why
> it's okay, just compute the `(strBufNextChar - strBufBegin)` offset a few
> lines earlier, before the realloc.

I did do that in new commit, and the warning has gone!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Thu May 12 01:32:42 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 12 May 2022 01:32:42 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4]
In-Reply-To: <hRz0_TToYgAPiC2722w2E0YzZztTp34v74R4OM6A78k=.f5ae0319-cd63-421a-b416-652757587567@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <hRz0_TToYgAPiC2722w2E0YzZztTp34v74R4OM6A78k=.f5ae0319-cd63-421a-b416-652757587567@github.com>
Message-ID: <cbS0XWcBC0vi8SjU3V3dS4feDWBnMbPjSyCXqoPGcb4=.f2cdf49d-0915-46b1-b436-e3699e94892c@github.com>

On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Calculate char offset before realloc()

Thanks for all to review this PR! I think we should separate this issue as following:

* Suppress warnings
    * make/modules/java.desktop/lib/Awt2dLibraries.gmk
    * src/hotspot/share/classfile/bytecodeAssembler.cpp
    * src/hotspot/share/classfile/classFileParser.cpp
    * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
    * src/hotspot/share/opto/memnode.cpp
    * src/hotspot/share/opto/type.cpp
    * src/hotspot/share/utilities/compilerWarnings.hpp
    * src/hotspot/share/utilities/compilerWarnings_gcc.hpp
    * src/java.base/unix/native/libjli/java_md_common.c
* Bug fixes
    * src/java.base/share/native/libjli/java.c
    * src/java.base/share/native/libjli/parse_manifest.c
    * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c

I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library.

I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From xgong at openjdk.java.net  Thu May 12 01:59:46 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 12 May 2022 01:59:46 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store
In-Reply-To: <72MBdW0hFE0o2NLg2I94Zw7y-ZJ7-SGVh5Pjz9mmOGI=.31b44f50-547a-4d79-a355-2705d0e8869e@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <72MBdW0hFE0o2NLg2I94Zw7y-ZJ7-SGVh5Pjz9mmOGI=.31b44f50-547a-4d79-a355-2705d0e8869e@github.com>
Message-ID: <sJETl1j62ULlycx4Ymmd2uFSjFdA4g0m9mOxuz3SJus=.a587d7a8-5b9f-4f28-bccc-c3bcb36b4e85@github.com>

On Wed, 11 May 2022 15:10:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
>> 
>> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
>> 
>> Benchmark                                   Before    After     Gain Units
>> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
>> 
>> Similar performane gain can also be observed on ARM hardware.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 4086:
> 
>> 4084:         } else {
>> 4085:             $Type$Species vsp = vspecies();
>> 4086:             if (offset < 0 || offset > (a.length - vsp.length())) {
> 
> Can we use `VectorIntrinsics.checkFromIndexSize`? e.g. 
> 
> if (!VectorIntrinsics.checkFromIndexSize(offset, vsp.length(), a.length)) { ...

Thanks for the review @PaulSandoz ! For the `VectorIntrinsics.checkFromIndexSize`, I'm afraid it's not suitable to be used here because the `outOfBounds` exception will be thrown if the offset is not inside of the valid array boundary. And  for the masked operations, this is not needed since we only need to check the masked lanes. Please correct me if I didn't understand correctly. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From iris at openjdk.java.net  Thu May 12 02:01:47 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 12 May 2022 02:01:47 GMT
Subject: RFR: JDK-8286615: Small refactor to SerializedLambda
In-Reply-To: <wpYuGehq7x3d8YRH0ja0_JRfNZy1ihXW3yldLUx5ZQc=.af897cbf-e942-4631-a6e9-37c73351a3cb@github.com>
References: <wpYuGehq7x3d8YRH0ja0_JRfNZy1ihXW3yldLUx5ZQc=.af897cbf-e942-4631-a6e9-37c73351a3cb@github.com>
Message-ID: <-grPCo4RlHSwiE9ySh2h5x20MrX7VYO3lD2u93loiBo=.63ceb675-8128-4e90-930c-e91821417c7a@github.com>

On Thu, 12 May 2022 00:10:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Noticed by inspection during a CSR review, small refactoring to use a message-cause exception constructor when one is available.
> 
> Will update the copyright before a push.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8670

From jpai at openjdk.java.net  Thu May 12 02:52:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 12 May 2022 02:52:40 GMT
Subject: RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled [v2]
In-Reply-To: <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
 <M7hZUmnwUhDAZFasPwwZNv8Nu0TDzHwC6V20iGZdkXw=.55d296de-c1ce-464f-a851-7fda2b3a4b72@github.com>
Message-ID: <GhYY1vxNW_Jone0eF9k-MAIRaMJ459oEOtbQY1sSd_Q=.418bdb49-e34e-42bf-b9f7-8fc8cf9e76b8@github.com>

On Wed, 11 May 2022 14:24:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`?
>> 
>> With this change the build now passes (tested both with bundled and system zlib variants).
>> 
>> tier1, tier2 and tier3 testing has been done and no related failures have been noticed.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - copyright years
>  - disable format-nonliteral warning when building LIBSPLASHSCREEN with bundled zlib
>  - Magnus' suggestion - make the LIBZ_CFLAGS more readable in the build file
>  - Magnus' suggestion - Disable format-nonliteral in build section of zlib instead of source code

Thank you Lance and Magnus for the reviews and inputs. I've triggered various build and test runs with this state of the PR. Once those complete satisfactorily, I'll go ahead and integrate this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8651

From dholmes at openjdk.java.net  Thu May 12 03:37:53 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 12 May 2022 03:37:53 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v10]
In-Reply-To: <JcFdQwOApAPaDk0YR_iAJLZ-KUBXT3KPz0LJaJU0XCA=.b095806e-5e87-4d52-a17b-762756169f2c@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <JcFdQwOApAPaDk0YR_iAJLZ-KUBXT3KPz0LJaJU0XCA=.b095806e-5e87-4d52-a17b-762756169f2c@github.com>
Message-ID: <xFXj9bYGLGV98x1bn-FiLLOcLFHWS7R3HIEGEuxkd20=.85db1338-1f52-4be7-a778-3e3ec38c0d94@github.com>

On Wed, 11 May 2022 17:51:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
>> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
>> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
>> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Block async exceptions during upcalls
>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>  - Fix use of rt_call
>  - Migrate to GrowableArray
>  - Address some review comments
>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>  - Remove unneeded ComputeMoveOrder
>  - Remove comment about native calls in lcm.cpp
>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>    
>    Reviewed-by: jvernee, mcimadamore
>  - Update riscv and arm stubs
>  - ... and 16 more: https://git.openjdk.java.net/jdk/compare/cdd006e7...b29ad8f4

src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3:

> 1: /*
> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2019, 2021, Arm Limited. All rights reserved.

Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example.
Also it is 2022. :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From dholmes at openjdk.java.net  Thu May 12 03:37:54 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 12 May 2022 03:37:54 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <WCNDNQabM_3gZBaog255y0LSokj044con0d23ZeQ7hA=.cfae3ed7-b420-47fc-bf73-f7f65cddf385@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
 <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
 <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>
 <T73dHwsxmGWzDhJzzaLzEkOpsi6LB7jHBwcBI-JTJlY=.3929d080-0ae2-4645-88db-f5dfa8f0e855@github.com>
 <AIN9VRXcDj-YKtSkychFW7_ZqXdx3AsWmeMnvzJchl8=.680b9133-929d-4a47-809a-2a654a94bf26@github.com>
 <WCNDNQabM_3gZBaog255y0LSokj044con0d23ZeQ7hA=.cfae3ed7-b420-47fc-bf73-f7f65cddf385@github.com>
Message-ID: <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com>

On Wed, 11 May 2022 20:27:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I went ahead and implemented this suggestion. Now we block async exceptions in on_entry, and unblock in on_exit.
>
> Is it possible for these upcalls to be nested? If yes, we could add a boolean to context to avoid unsetting the flag in those nested cases. And now that I think we should probably add that check in NoAsyncExceptionDeliveryMark too if we allow broader use of this flag. David added the NoAsyncExceptionDeliveryMark code with that assert about nesting so maybe he might have more insights about that.

NoAsyncExceptionDeliveryMark is not for general use! There is no provision for blocking async exceptions when running user-defined Java code. NoAsyncExceptionDeliveryMark was purely for protecting "system Java code".

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From psandoz at openjdk.java.net  Thu May 12 03:39:43 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 12 May 2022 03:39:43 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store
In-Reply-To: <sJETl1j62ULlycx4Ymmd2uFSjFdA4g0m9mOxuz3SJus=.a587d7a8-5b9f-4f28-bccc-c3bcb36b4e85@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <72MBdW0hFE0o2NLg2I94Zw7y-ZJ7-SGVh5Pjz9mmOGI=.31b44f50-547a-4d79-a355-2705d0e8869e@github.com>
 <sJETl1j62ULlycx4Ymmd2uFSjFdA4g0m9mOxuz3SJus=.a587d7a8-5b9f-4f28-bccc-c3bcb36b4e85@github.com>
Message-ID: <tqNGoFG1OnNbyuQrTu5HsE9_aI8XJR8buJbZxDINVBY=.f65b24f6-1301-452a-8c09-c5fb3f1d8cc5@github.com>

On Thu, 12 May 2022 01:56:25 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template line 4086:
>> 
>>> 4084:         } else {
>>> 4085:             $Type$Species vsp = vspecies();
>>> 4086:             if (offset < 0 || offset > (a.length - vsp.length())) {
>> 
>> Can we use `VectorIntrinsics.checkFromIndexSize`? e.g. 
>> 
>> if (!VectorIntrinsics.checkFromIndexSize(offset, vsp.length(), a.length)) { ...
>
> Thanks for the review @PaulSandoz ! For the `VectorIntrinsics.checkFromIndexSize`, I'm afraid it's not suitable to be used here because the `outOfBounds` exception will be thrown if the offset is not inside of the valid array boundary. And  for the masked operations, this is not needed since we only need to check the masked lanes. Please correct me if I didn't understand correctly. Thanks!

Silly me! i commented too quickly, `checkFromIndexSize` cannot be used. My intent was that we could use a method rather than repeating the expression in numerous places (including masked loads IIRC).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From xgong at openjdk.java.net  Thu May 12 03:42:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 12 May 2022 03:42:40 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <P3jW_5XRZQBmYrG71DRds1UC2LlG87EzDkQ3NB9Xh48=.25df21b3-bb06-4c45-ad81-21f2cfd25e93@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <P3jW_5XRZQBmYrG71DRds1UC2LlG87EzDkQ3NB9Xh48=.25df21b3-bb06-4c45-ad81-21f2cfd25e93@github.com>
Message-ID: <rOnddSQdy1u2l9X9qbQHmBo9J2MoVADGWScIjoN8HcY=.e6bf7d38-72a7-42f9-aca3-119ee0b61e4b@github.com>

On Wed, 11 May 2022 19:45:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I tried your test code with the patch and logged compilation (`-XX:-TieredCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:+PrintIntrinsics -Xbatch`)
> 
> For `func` the first call to `VectorSupport::loadMasked` is intrinsic and inlined:
> 
> ```
>     @ 45   jdk.internal.vm.vector.VectorSupport::loadMasked (40 bytes)   (intrinsic)
> ```
> 
> But the second call (for the last loop iteration) fails to inline:
> 
> ```
>     @ 45   jdk.internal.vm.vector.VectorSupport::loadMasked (40 bytes)   failed to inline (intrinsic)
> ```
> 
> Since i am running on an mac book this looks right and aligns with the `-XX:+PrintIntrinsics` output:
> 
> ```
>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>   ** not supported: op=loadMasked vlen=8 etype=int using_byte_array=0
> ```
> 
> ?
> 
> I have not looked at the code gen nor measured performance comparing the case when never out of bounds and only out of bounds for the last loop iteration.

Yeah, it looks right from the log. Did you try to find whether there is the log `** missing constant: offsetInRange=Parm` with `XX:+PrintIntrinsics` ? Or insert an assertion in `vectorIntrinsics.cpp` like:

--- a/src/hotspot/share/opto/vectorIntrinsics.cpp
+++ b/src/hotspot/share/opto/vectorIntrinsics.cpp
@@ -1236,6 +1236,7 @@ bool LibraryCallKit::inline_vector_mem_masked_operation(bool is_store) {
     } else {
       // Masked vector load with IOOBE always uses the predicated load.
       const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int();
+      assert(offset_in_range->is_con(), "must be a constant");
       if (!offset_in_range->is_con()) {
         if (C->print_intrinsics()) {
           tty->print_cr("  ** missing constant: offsetInRange=%s",

And run the tests with debug mode.  Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From xgong at openjdk.java.net  Thu May 12 03:43:49 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 12 May 2022 03:43:49 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store
In-Reply-To: <tqNGoFG1OnNbyuQrTu5HsE9_aI8XJR8buJbZxDINVBY=.f65b24f6-1301-452a-8c09-c5fb3f1d8cc5@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <72MBdW0hFE0o2NLg2I94Zw7y-ZJ7-SGVh5Pjz9mmOGI=.31b44f50-547a-4d79-a355-2705d0e8869e@github.com>
 <sJETl1j62ULlycx4Ymmd2uFSjFdA4g0m9mOxuz3SJus=.a587d7a8-5b9f-4f28-bccc-c3bcb36b4e85@github.com>
 <tqNGoFG1OnNbyuQrTu5HsE9_aI8XJR8buJbZxDINVBY=.f65b24f6-1301-452a-8c09-c5fb3f1d8cc5@github.com>
Message-ID: <8C21uEnaFRrKP-kr3s-a1_NT27G4mNnbGKAeV4595mA=.29184b9e-916e-40bf-b68a-21ffebd0b5cc@github.com>

On Thu, 12 May 2022 03:36:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Thanks for the review @PaulSandoz ! For the `VectorIntrinsics.checkFromIndexSize`, I'm afraid it's not suitable to be used here because the `outOfBounds` exception will be thrown if the offset is not inside of the valid array boundary. And  for the masked operations, this is not needed since we only need to check the masked lanes. Please correct me if I didn't understand correctly. Thanks!
>
> Silly me! i commented too quickly, `checkFromIndexSize` cannot be used. My intent was that we could use a method rather than repeating the expression in numerous places (including masked loads IIRC).

Good idea! I will try. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From dholmes at openjdk.java.net  Thu May 12 04:09:41 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 12 May 2022 04:09:41 GMT
Subject: RFR: 8286560: Remove user parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>
References: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>
Message-ID: <JQ_ylMKNoRy1kkoWipgbfViPWTJf1BI74vWQwMaCF1o=.abb9c0d8-68b6-4abc-af88-8e5dd3ce3312@github.com>

On Wed, 11 May 2022 23:08:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed.

Nice cleanup! I checked back in JDK 7 and couldn't find any use of this particular API.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8669

From almatvee at openjdk.java.net  Thu May 12 04:15:50 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 12 May 2022 04:15:50 GMT
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe [v2]
In-Reply-To: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
Message-ID: <BtITAMIGuPEYwTYNhIHiSepf6tS1nr5Eu_BHGz1Zw14=.4c77c962-801f-419f-82e8-39971325961a@github.com>

> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.
>  - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles.
>  - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error.
>  - Added two tests to validate fix.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8666/files
  - new: https://git.openjdk.java.net/jdk/pull/8666/files/4b3c8754..c9ebcee1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8666&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8666&range=00-01

  Stats: 16 lines in 2 files changed: 3 ins; 4 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8666.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8666/head:pull/8666

PR: https://git.openjdk.java.net/jdk/pull/8666

From almatvee at openjdk.java.net  Thu May 12 04:15:53 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 12 May 2022 04:15:53 GMT
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe [v2]
In-Reply-To: <YGkae8ZT4Kxe5dpcPQtUuBxYdT43TlcE3sDz9tlWLEM=.be671d51-56a7-4533-94b9-7b47a1cfa828@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <YGkae8ZT4Kxe5dpcPQtUuBxYdT43TlcE3sDz9tlWLEM=.be671d51-56a7-4533-94b9-7b47a1cfa828@github.com>
Message-ID: <lpquqr37Mp5xQNuLVr36UfzalIwddKKdLmBMqJLlbJY=.fdb94a19-44f2-47f8-9ef6-8a5202637a15@github.com>

On Wed, 11 May 2022 21:58:46 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]
>
> test/jdk/tools/jpackage/macosx/MacAppStoreJlinkOptionsTest.java line 48:
> 
>> 46: 
>> 47:     @Test
>> 48:     public static void test() throws Exception {
> 
> I'd give some more descriptive names to test functions than `test` and `test2`. Something like `testWithStripNativeCommands` and `testWithoutStripNativeCommands` maybe?

Fixed.

> test/jdk/tools/jpackage/macosx/MacAppStoreRuntimeTest.java line 102:
> 
>> 100: 
>> 101:         cmd.execute(1);
>> 102:     }
> 
> @Test
> @Parameter("true")
> @Parameter("false")
> public static void test(boolean stripNativeCommands) throws Exception {
>     JPackageCommand cmd = JPackageCommand.helloAppImage();
>     cmd.addArguments("--mac-app-store", "--runtime-image", getRuntimeImage(stripNativeCommands));
> 
>     if (stripNativeCommands) {
>         cmd.executeAndAssertHelloAppImageCreated();
>     } else {
>         cmd.execute(1);
>     }
> }

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8666

From dholmes at openjdk.java.net  Thu May 12 04:28:43 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 12 May 2022 04:28:43 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <Qs8Wm4J27rP2T1O2OJVMQk059XiFUT5I3mpp1bHKRMI=.defc31d7-0e77-4c54-bdba-eac38106647a@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
 <Qs8Wm4J27rP2T1O2OJVMQk059XiFUT5I3mpp1bHKRMI=.defc31d7-0e77-4c54-bdba-eac38106647a@github.com>
Message-ID: <kNgCZx5QuWg5CJ9zdsqsgzzagti0sUYLMONKkPDdMNs=.92fd26d6-cf10-419d-8a6d-2d9a7a3b1d38@github.com>

On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust API level to Windows 8 for security.cpp and do some cleanup
>
> This change seem to have made this group of declarations obsolete: 
> `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link](
> https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself.

@mkartashev  all references to WINVER in the AWT code seem obsolete. Possibly most of the IS_WINxxx usages could also be replaced.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From alexander.matveev at oracle.com  Thu May 12 04:38:06 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 12 May 2022 04:38:06 +0000
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
Message-ID: <8C1C5A6D-6D14-48B0-8C5A-9D9EE18A78A0@oracle.com>

Hi Michael,

> On May 11, 2022, at 3:17 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> Is this restricted somehow to Mac App Store applications?
Yes, helper tools (in our case JDK native commands) in Mac App Store applications cannot use same bundle ID as another application. Since we have bundle ID embedded in native commands multiple applications cannot use it without updating each native command with unique bundle ID and since they embedded inside executable I do not see how it would be possible to change during packaging.
> 
> Is a warning issued as stripping native commands  may break application functionality?
No, error will be issues and jpackage will exit with error if ?mac-app-store arguments is used and provided runtime has native tools or user did not specified --strip-native-commands to jlink.
> 
> Is it not possible for the user to provide their own Info.plist with  a different bundle identifier that doesn?t collide?
Not possible due to native commands have embedded Info.plist.
> 
> I?m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?
Yes, it should be possible and in theory such JDK with native commands can be used. However, current fix will not allow such JDK build, since we checking for presence of ?bin? folder and not if ID is actually unique. To work around this limitation user can package without native commands first, then add native commands and re-sign application.

> Or just change it in the current build so it doesn?t collide? With the application or whatever one it is colliding with.
Not possible, since ID should be unique per application.

Thanks,
Alexander

From mik3hall at gmail.com  Thu May 12 05:40:49 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 12 May 2022 00:40:49 -0500
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <8C1C5A6D-6D14-48B0-8C5A-9D9EE18A78A0@oracle.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
 <8C1C5A6D-6D14-48B0-8C5A-9D9EE18A78A0@oracle.com>
Message-ID: <0441CF7A-8653-41E8-B084-A7F4863991D6@gmail.com>

Alexander

> On May 11, 2022, at 11:38 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
>> On May 11, 2022, at 3:17 PM, Michael Hall <mik3hall at gmail.com> wrote:
>> 
>> Is this restricted somehow to Mac App Store applications?
> Yes, helper tools (in our case JDK native commands) in Mac App Store applications cannot use same bundle ID as another application. Since we have bundle ID embedded in native commands multiple applications cannot use it without updating each native command with unique bundle ID and since they embedded inside executable I do not see how it would be possible to change during packaging.

Possibly not during packaging but during the jdk build of the native commands? Somehow the Info.plist must be getting embedded and a bundle id provided. I?m not sure where or how. But one way to get uniqueness if the id is provided to embed the Info.plist in the native command executable compile/link  would be to include the command as part of the identifier. Something like CFBundleID = java.native.cmd or CFBundleID = javac.native.cmd. 

>> 
>> Is a warning issued as stripping native commands  may break application functionality?
> No, error will be issues and jpackage will exit with error if ?mac-app-store arguments is used and provided runtime has native tools or user did not specified --strip-native-commands to jlink.

A warning might be sufficient if the commands are included accidentally by the user unintentionally omitting the ?strip-native-commands with the jlink options. Then just force the ?strip-native-commands option. It might be the application will just lose some non-critical functionality even if they meant to have the native command included.

>> Is it not possible for the user to provide their own Info.plist with  a different bundle identifier that doesn?t collide?
> Not possible due to native commands have embedded Info.plist.

Maybe I?m misunderstanding the conflict. Are the commands conflicting with the application level Info.plist or with each other? I believe jpackage usually has a mechanism where a substitute Info.plist can be used if the conflict is with the application level. If multiple commands are conflicting with each other this won?t work.

>> 
>> I?m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?
> Yes, it should be possible and in theory such JDK with native commands can be used. However, current fix will not allow such JDK build, since we checking for presence of ?bin? folder and not if ID is actually unique. To work around this limitation user can package without native commands first, then add native commands and re-sign application.

Signing is currently an integrated part of the process. I thought about making an enhancement request to have it possible to do it stepped. First build the application, then allow the user to post-process that. Maybe run a tool/script to modify the application level Info.plist file. Then allow a second final step that does the signing. I don?t remember if I actually made that enhancement request. But currently there is no way with jpackage to standalone sign the application is there? I think this is somewhat involved with the application bundle being iterated and for one thing each jar being separately code signed? I think it took a release or two of the command to get this correct. So I doubt Xcode could manage it. Is there a way to do the signing standalone with jpackage that I am not aware of?

If I didn?t do an enhancement request on this I could, if you think jpackage could manage it?
 
> 
>> Or just change it in the current build so it doesn?t collide? With the application or whatever one it is colliding with.
> Not possible, since ID should be unique per application.

Possibly you are misunderstanding me here I think you already indicated the could be done ?in theory?. It still seems possibly the correct ?fix?. Change the build so uniqueness is not an issue.
> 
> Thanks,
> Alexander

Thanks,
Mike


From iklam at openjdk.java.net  Thu May 12 06:16:45 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 12 May 2022 06:16:45 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
In-Reply-To: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
Message-ID: <Tb2H9w2gDKJ7c4-dlu08OxlxhOvXac4KI_ZPU0bakT8=.1f13223a-8a2c-42a4-bae9-d5f78ed81c10@github.com>

On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
> 
> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
> 
> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
> 
> Testing:
> - [x] Added unit tests
> - [x] GHA
> - [x] Container tests on cgroups v1 Linux. Continue to pass

I just started to look at the code so just one comment for now.

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 65:

> 63:                             path = mountPoint + cgroupSubstr;
> 64:                         }
> 65:                     } else {

Looks like `path` is still not set if the condition at line 61 `if (cgroupPath.length() > root.length()) {` is false.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From duke at openjdk.java.net  Thu May 12 06:32:56 2022
From: duke at openjdk.java.net (Shruthi)
Date: Thu, 12 May 2022 06:32:56 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v7]
In-Reply-To: <-r3ALnm_qKjys-U2GxzdJykWJUglWqMdBglBPdmiBKs=.b8664eec-5cdc-4e6c-85f4-6c48bd393d78@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <-r3ALnm_qKjys-U2GxzdJykWJUglWqMdBglBPdmiBKs=.b8664eec-5cdc-4e6c-85f4-6c48bd393d78@github.com>
Message-ID: <R9x8ZH_xGhSoMUgTRfuBc_AUn5MCEWfSMEtFx5BNfPw=.c9c768bd-0ea6-468f-ba39-1005ed75d740@github.com>

On Wed, 11 May 2022 05:22:22 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modify copyright year

`/integrate`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Thu May 12 06:51:20 2022
From: duke at openjdk.java.net (KIRIYAMA Takuya)
Date: Thu, 12 May 2022 06:51:20 GMT
Subject: RFR: 8281268: Resolve duplication of test ClassTransformer class
Message-ID: <0LDP8tblKUqLt0fcYtmlJ2Mu8hRCBh7rvge6Muo7dtg=.04497b51-993a-4f3b-984f-65ece6addcfd@github.com>

ClassTransformer.java is duplicated because ClassTransformer.java was copied from test/jdk/com/sun/jdi/lib/jdb to test/lib/jdk/test/lib/util at [JDK-8240908](https://bugs.openjdk.java.net/browse/JDK-8240908). test/lib/jdk/test/lib/util/ClassTransformer.java should be deleted and test/jdk/com/sun/jdi/lib/jdb/ClassTransformer.java should be used. This is because ClassTransformer is used for testing jdi, and it is not appropriate to exist in test/lib/jdk/test/lib/util.
Would you please review this fix?

-------------

Commit messages:
 - 8281268: Resolve duplication of test ClassTransformer class

Changes: https://git.openjdk.java.net/jdk/pull/8672/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8672&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281268
  Stats: 165 lines in 2 files changed: 0 ins; 163 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8672.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8672/head:pull/8672

PR: https://git.openjdk.java.net/jdk/pull/8672

From mbaesken at openjdk.java.net  Thu May 12 07:31:50 2022
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 12 May 2022 07:31:50 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <Qs8Wm4J27rP2T1O2OJVMQk059XiFUT5I3mpp1bHKRMI=.defc31d7-0e77-4c54-bdba-eac38106647a@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
 <Qs8Wm4J27rP2T1O2OJVMQk059XiFUT5I3mpp1bHKRMI=.defc31d7-0e77-4c54-bdba-eac38106647a@github.com>
Message-ID: <qIb-uUMqeDbmUrDOAEaf9rg8xUP-SEEHt5yRKWpS-mM=.efdd6562-e392-40d5-9690-7b74fe5869d2@github.com>

On Wed, 11 May 2022 16:00:32 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> This change seem to have made this group of declarations obsolete: `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link](https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself.

Hi Maxim, no plans from me, so feel free to do further cleanups.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From jpai at openjdk.java.net  Thu May 12 08:13:56 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 12 May 2022 08:13:56 GMT
Subject: Integrated: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled
In-Reply-To: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
References: <mhlWcFPkPqj6em7BAOFl184virogAJeHHtLlgoZJgOg=.05608e78-0284-49ef-9f62-c1bd6b8d09a1@github.com>
Message-ID: <InpfetEGIoaBKMyMtLKGprHpwCE0ralt4rXvObn03qc=.9742bd3d-ca6b-4f09-84b3-f29c98860e46@github.com>

On Wed, 11 May 2022 11:38:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which fixes build failures on macos when using `--with-zlib=bundled`?
> 
> With this change the build now passes (tested both with bundled and system zlib variants).
> 
> tier1, tier2 and tier3 testing has been done and no related failures have been noticed.

This pull request has now been integrated.

Changeset: 50d47de8
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/50d47de8358e2f22bf3a4a165d660c25ef6eacbc
Stats:     9 lines in 3 files changed: 5 ins; 0 del; 4 mod

8286582: Build fails on macos aarch64 when using --with-zlib=bundled

Reviewed-by: ihse, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8651

From jhendrikx at openjdk.java.net  Thu May 12 08:20:56 2022
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Thu, 12 May 2022 08:20:56 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v3]
In-Reply-To: <3eDsmvMyBrMn89BpVmMcG6Xyb3m5vM8DzKV-vDhxFXY=.a1553712-81f4-4434-9522-e7dbd7fbbb60@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <3eDsmvMyBrMn89BpVmMcG6Xyb3m5vM8DzKV-vDhxFXY=.a1553712-81f4-4434-9522-e7dbd7fbbb60@github.com>
Message-ID: <_D7JUQjjeAtDWiSqQOTt5rA-EyHcb8ChA5JKnaIYoQw=.cf6b8e50-ece7-46fd-8327-b9b8f7dddf56@github.com>

On Thu, 5 May 2022 23:39:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.
>
> Brian Burkhalter 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:
> 
>  - 6478546: Clean up io_util.c
>  - Merge
>  - 6478546: Decrease malloc'ed buffer maximum size to 64 kB
>  - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

src/java.base/share/native/libjava/io_util.c line 79:

> 77:           jint off, jint len, jfieldID fid)
> 78: {
> 79:     char stackBuf[STACK_BUF_SIZE];

This was in the original code already, but doesn't this always allocate 8k on the stack, regardless of whether this buffer will be used (if len > 8k or len == 0)?  Wouldn't it be better to allocate this only in the `else` case?

Would apply to the write code as well.

src/java.base/share/native/libjava/io_util.c line 81:

> 79:     char stackBuf[STACK_BUF_SIZE];
> 80:     char *buf = NULL;
> 81:     jint buf_size, read_size;;

minor: double semi colon

src/java.base/share/native/libjava/io_util.c line 129:

> 127:             off += n;
> 128:         } else if (n == -1) {
> 129:             JNU_ThrowIOExceptionWithLastError(env, "Read error");

The original code would have `nread` set to `-1` here, and thus exit with `-1`.  The new code would exit with the last value for `nread` which could be anything.

src/java.base/share/native/libjava/io_util.c line 201:

> 199:         write_size = len < buf_size ? len : buf_size;
> 200:         (*env)->GetByteArrayRegion(env, bytes, off, write_size, (jbyte*)buf);
> 201:         if (!(*env)->ExceptionOccurred(env)) {

Wouldn't this result in an infinite loop if `GetByteArrayRegion` triggered an exception and `len > 0` ?  It would never enter the `if` and `len` is never changed then...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8235

From ngasson at openjdk.java.net  Thu May 12 08:27:00 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 12 May 2022 08:27:00 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v10]
In-Reply-To: <xFXj9bYGLGV98x1bn-FiLLOcLFHWS7R3HIEGEuxkd20=.85db1338-1f52-4be7-a778-3e3ec38c0d94@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <JcFdQwOApAPaDk0YR_iAJLZ-KUBXT3KPz0LJaJU0XCA=.b095806e-5e87-4d52-a17b-762756169f2c@github.com>
 <xFXj9bYGLGV98x1bn-FiLLOcLFHWS7R3HIEGEuxkd20=.85db1338-1f52-4be7-a778-3e3ec38c0d94@github.com>
Message-ID: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com>

On Thu, 12 May 2022 03:34:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Block async exceptions during upcalls
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Fix use of rt_call
>>  - Migrate to GrowableArray
>>  - Address some review comments
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - ... and 16 more: https://git.openjdk.java.net/jdk/compare/cdd006e7...b29ad8f4
>
> src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (c) 2019, 2021, Arm Limited. All rights reserved.
> 
> Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example.
> Also it is 2022. :)

I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From duke at openjdk.java.net  Thu May 12 08:44:49 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 12 May 2022 08:44:49 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF
In-Reply-To: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
Message-ID: <HIcmZHW9p-POTlA5EGDM8QSkK7Jqrp68w2xNDdZNNQs=.06c9803e-7981-4732-aae3-4d9e234b9b79@github.com>

On Wed, 11 May 2022 20:47:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the specification of `SequenceInputStream.read(byte[],int,int)` to indicate that `-1` is returned at the EOF of the last stream even if `len` is zero.

Also, in the current implementation, when the end of the last contained stream has been reached and `-1` is returned, none of the arguments is checked, so a caller can pass `null` for `b` or out of bounds indices `off` and `len`. This is at odd with the `@throws` clauses.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8664

From jpai at openjdk.java.net  Thu May 12 08:56:49 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 12 May 2022 08:56:49 GMT
Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64
In-Reply-To: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
References: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
Message-ID: <rsENiMrm5arSu6icpkfG-rJ9M8BAcpIb8RTmXwdOLJ0=.987192e3-5bc3-4541-a9f3-e727704f2734@github.com>

On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? 
> 
> We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. 
> We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64.

Dummy comment to initiate a mail to core-libs mailing list too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8675

From jvernee at openjdk.java.net  Thu May 12 09:28:59 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 09:28:59 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v11]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <JMTHCHr5klFWK2_Er-5y4da0W8wX3IvZDXMvdWSJFgE=.30ca0d92-3389-41e7-86ec-0e724418ba3c@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Block async exceptions during upcalls"
  
  This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/b29ad8f4..1c04a42e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=09-10

  Stats: 25 lines in 3 files changed: 0 ins; 21 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Thu May 12 09:29:00 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 09:29:00 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
 <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
 <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>
 <T73dHwsxmGWzDhJzzaLzEkOpsi6LB7jHBwcBI-JTJlY=.3929d080-0ae2-4645-88db-f5dfa8f0e855@github.com>
 <AIN9VRXcDj-YKtSkychFW7_ZqXdx3AsWmeMnvzJchl8=.680b9133-929d-4a47-809a-2a654a94bf26@github.com>
 <WCNDNQabM_3gZBaog255y0LSokj044con0d23ZeQ7hA=.cfae3ed7-b420-47fc-bf73-f7f65cddf385@github.com>
 <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com>
Message-ID: <vO8ppClc_A5MhswLQXuTi-T2_3RAoTg6X69O1sbQVI8=.15e3f5c1-7bed-4d73-a703-e3737b9f3a4a@github.com>

On Thu, 12 May 2022 03:32:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Is it possible for these upcalls to be nested? If yes, we could add a boolean to context to avoid unsetting the flag in those nested cases. And now that I think we should probably add that check in NoAsyncExceptionDeliveryMark too if we allow broader use of this flag. David added the NoAsyncExceptionDeliveryMark code with that assert about nesting so maybe he might have more insights about that.
>
> NoAsyncExceptionDeliveryMark is not for general use! There is no provision for blocking async exceptions when running user-defined Java code. NoAsyncExceptionDeliveryMark was purely for protecting "system Java code".

Okay, I see. I think I acted a little too hastily on this yesterday.  I'll revert the change that uses this blocking mechanism.

The stack more or less looks like this during an upcall:


| ---
| <younger frames> |
| ---
| <1: user define try block with exception handler (maybe)> |
| ---
| <2: user code start> |
| ---
| <3: method handle impl frames 1> |
| ---
| <4: upcall wrapper class with fallback handler 1> |
| ---
| <5: method handle impl frames 2> |
| ---
| <6: upcallk stub with fallback handler 2> |
| <7: unknown native code>
| ---
| <older frames> |


I think there are several options to address async exceptions:
1. Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will up in one of the fallback handlers and the VM will be terminated.
2. Block async exceptions in all code up from 6.
3. Somehow only block async exceptions only between 6. and 1. 
    I think that is possible by changing the API so that the user passes us a method handle to their fallback exception handler. We would need 2 methods for blocking and unblocking async exceptions from Java. Then we could disable async exceptions at the start of 6. enabled them at the start of the try block in 4. (around the call to user code), and disable them at the end of this try block. Then finally re-enable them at the end of 6. If an exception occurs in the try block in 4., delegate to the user-defined exception handler (but use the VM terminate strategy as a fallback for when another exception occurs). The other problem I see with that is that to make that fast enough (i.e. not incur a ~1.5-2x cost on call overhead), we would need compiler intrinsics for the blocking/unblocking, and in the past we've been unable to define 'critical' sections of code like that in C2 (it's an unsolved problem at this point).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Thu May 12 09:31:36 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 09:31:36 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v10]
In-Reply-To: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <JcFdQwOApAPaDk0YR_iAJLZ-KUBXT3KPz0LJaJU0XCA=.b095806e-5e87-4d52-a17b-762756169f2c@github.com>
 <xFXj9bYGLGV98x1bn-FiLLOcLFHWS7R3HIEGEuxkd20=.85db1338-1f52-4be7-a778-3e3ec38c0d94@github.com>
 <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com>
Message-ID: <vD7ThpOiXhohLuOLA9pjMZ_I5bJ9wv-P2Cmxy6ikY3o=.87436d7a-149a-4a74-bb56-a754c9bee0a4@github.com>

On Thu, 12 May 2022 08:23:11 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.
>>> 3:  * Copyright (c) 2019, 2021, Arm Limited. All rights reserved.
>> 
>> Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example.
>> Also it is 2022. :)
>
> I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo.

Right, I brought in these commits from the Panama repo, so this is from Nick's updates there (specifically from this PR: https://github.com/openjdk/panama-foreign/pull/610).

I'm not sure what to do here. I own the PR, but Nick is a contributor on it, so some of the changes are his (including this copyright year change).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From magnus.ihse.bursie at oracle.com  Thu May 12 09:42:15 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 May 2022 11:42:15 +0200
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
Message-ID: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com>

(cc:ing build-dev.)

On 2022-05-12 00:17, Michael Hall wrote:
> Is this restricted somehow to Mac App Store applications?
>
> Is a warning issued as stripping native commands  may break application functionality?
>
> Is it not possible for the user to provide their own Info.plist with  a different bundle identifier that doesn?t collide?
>
> I?m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?
This problem seem to come about as a clash between the the OpenJDK 
packages themselves being submitted to Apple, as well as a 
developer-specific jpackage containing JDK binaries, such as java.

The well-written response from Apple tech support in the original web 
bug is very instructive. I'll quote it in its entirety:

----
> I?ve dealt with this message before, and it has a long and interesting 
> history. The Mac App Store prevents two developers from submitting 
> executables with the same bundle identifier. This is an important 
> security check: We don?t want app A impersonating app B.
>
> This check applies to all executables, not just the app?s main 
> executable. Historically the Mac App Store ingestion process had bugs 
> that caused it to apply to other types of code, like frameworks and 
> bundles. When I first saw this incident I was worried that these bugs 
> had come back.
>
> However, that?s not the case. Let?s look at the main executables in 
> your app:
>
> % find APP_NAME.app -type f -print0 | xargs -0 file | grep 
> "Mach-O.*executable"
> APP_NAME.app/Contents/MacOS/APP_NAME: Mach-O 64-bit executable x86_64
> APP_NAME.app/Contents/runtime/Contents/Home/bin/java: Mach-O 64-bit 
> executable x86_64
> APP_NAME.app/Contents/runtime/Contents/Home/bin/keytool: Mach-O 64-bit 
> executable x86_64
> APP_NAME.app/Contents/runtime/Contents/Home/lib/jspawnhelper: Mach-O 
> 64-bit executable x86_64
>
> Based on the error message it?s obvious we need to focus on the `java` 
> executable. However, it?s placed in a location that doesn?t have a 
> corresponding `Info.plist` file:
>
> % find APP_NAME.app -name "Info.plist"
> APP_NAME.app/Contents/Info.plist
> APP_NAME.app/Contents/runtime/Contents/Info.plist
>
> The first file here applies to your entire app and the second file 
> applies to the Java runtime package as a whole. Moreover, neither of 
> these have a bundle ID that matches the error message:
>
> % plutil -extract CFBundleIdentifier raw -o - 
> "APP_NAME.app/Contents/Info.plist"
> UNIQUE.BUNDLE.ID
> % plutil -extract CFBundleIdentifier raw -o - 
> "APP_NAME.app/Contents/runtime/Contents/Info.plist"
> com.oracle.java.com.UNIQUE.BUNDLE.ID
>
> So where is this bundle ID coming from?
>
> * * *
>
> Some further spelunking reveals the issue. Consider this:
>
> % otool -s __TEXT __info_plist -v 
> APP_NAME.app/Contents/runtime/Contents/Home/bin/java
> ?
> <dict>
> <key>CFBundleIdentifier</key>
> <string>net.java.openjdk.java</string>
> ?
> </dict>
> </plist>
>
> This is an obscure corner case in the macOS bundle story: A standalone 
> tool, like `java`, which isn?t in a bundle structure, and thus can?t 
> have a standalone `Info.plist` file, can put its information property 
> list in a `__TEXT` / `__info_plist` section within its executable. And 
> it seems that the folks who created your Java runtime did just that.
>
> Given that, the Mac App Store error is valid: You are trying to submit 
> an executable whose bundle ID matches some existing app.
>
> To get around this check you?ll need to give `java` a new bundle ID. 
> That?s not easy to do. This `__TEXT` / `__info_plist` section is set 
> up by a linker option (see `-sectcreate` in <x-man-page://1/ld&gt;) 
> <x-man-page://1/ld>)> and there?s no good way to modify it after the 
> fact [1].
>
> At this point my advice is that you escalate this with your Java 
> runtime vendor. I suspect that they?ve added this information property 
> list to get around a TCC check ? the only other interesting property 
> in there is `NSMicrophoneUsageDescription` ? and they probably didn?t 
> notice this Mac App Store submission issue. There?s a couple of ways 
> they could resolve this [2] but it?s really their issue to resolve.
>
> [1] And by ?good? I mean ?Using a standard tool supplied by Apple.? 
> The Mach-O file format is reasonably well documented and thus you 
> could build a custom tool to do that, but even that?s not easy. There 
> are a couple of problems:
>
> * The new information property list may be larger than the previous one.
>
> * The `__info_plist` section can appear anywhere in the `__TEXT` segment.
>
> If you increase the size of the section then subsequent sections need 
> to move up to accommodate it and, depending on which sections you have 
> to move, that might require other cross-section links to be fixed up. 
> Yergh!
>
> [2] The ones that spring to mind are:
>
> * Package the `java` executable in a standard bundle, replacing 
> `runtime/Contents/Home/bin/java` with a symlink to that.
>
> * Add an `__info_plist` section with a bunch of padding and then build 
> a tool to update the bundle ID in that section, taking advantage of 
> that padding to avoid the need to move subsequent sections in the 
> `__TEXT` segment. 

----

So maybe a better, or at least alternative, way of dealing with this 
issue is changing how the OpenJDK binaries are built.

I will need to do some reading up on the macOS bundle format to fully 
grok what our options are here.

/Magnus

From duke at openjdk.java.net  Thu May 12 09:50:39 2022
From: duke at openjdk.java.net (xpbob)
Date: Thu, 12 May 2022 09:50:39 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v16]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <_fy0_qvRPy9OmYxuNLe56sP2ycIyhEUaUEgJ3uV2rOs=.dcd42c1e-ee38-44f8-a1bd-093ed2c14d58@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  add swap method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/abd5a2b4..296a409e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=14-15

  Stats: 21 lines in 2 files changed: 16 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Thu May 12 09:53:17 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 12 May 2022 09:53:17 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store
In-Reply-To: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
Message-ID: <h_dBFf-GImm34qGOacTsrYWt73EyjMmzSGDywaytZEA=.6754f31f-23ad-4205-986a-799b594039bc@github.com>

On Tue, 10 May 2022 01:23:55 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
> 
> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
> 
> Benchmark                                   Before    After     Gain Units
> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
> 
> Similar performane gain can also be observed on ARM hardware.

Maybe we could use `a.length - vsp.length() > 0 && offset u< a.length - vsp.length()` which would hoist the first check outside of the loop.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From duke at openjdk.java.net  Thu May 12 09:54:49 2022
From: duke at openjdk.java.net (xpbob)
Date: Thu, 12 May 2022 09:54:49 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v16]
In-Reply-To: <_fy0_qvRPy9OmYxuNLe56sP2ycIyhEUaUEgJ3uV2rOs=.dcd42c1e-ee38-44f8-a1bd-093ed2c14d58@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <_fy0_qvRPy9OmYxuNLe56sP2ycIyhEUaUEgJ3uV2rOs=.dcd42c1e-ee38-44f8-a1bd-093ed2c14d58@github.com>
Message-ID: <tK-foHmeZy1yyDg76GPNUeB83m3GHxn2h6vRlGkLKgI=.89149e25-96a9-4bb6-a342-5e32fa540317@github.com>

On Thu, 12 May 2022 09:50:39 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add swap method

Thanks for review.
@jerboaa 
I recently had a minor operation, so I couldn't get back on time.
Read values in different places, I added a method read_mem_swappiness
Is that possible?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From sgehwolf at openjdk.java.net  Thu May 12 10:07:31 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 10:07:31 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
In-Reply-To: <Tb2H9w2gDKJ7c4-dlu08OxlxhOvXac4KI_ZPU0bakT8=.1f13223a-8a2c-42a4-bae9-d5f78ed81c10@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <Tb2H9w2gDKJ7c4-dlu08OxlxhOvXac4KI_ZPU0bakT8=.1f13223a-8a2c-42a4-bae9-d5f78ed81c10@github.com>
Message-ID: <AuSTxEhK-QJ31UQvQX2lApJy8iwOqhtnwscBoh9Qd4k=.b6e8aadc-e28d-4f16-a63c-e874c5055aa3@github.com>

On Thu, 12 May 2022 06:11:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 65:
> 
>> 63:                             path = mountPoint + cgroupSubstr;
>> 64:                         }
>> 65:                     } else {
> 
> Looks like `path` is still not set if the condition at line 61 `if (cgroupPath.length() > root.length()) {` is false.

Yes. There are more cases where the cgroup path might be null. If you know of cases that should be handled and aren't, please do let me know. Incidentally, that's why I've added the catch for NPE in `CgroupV1Subsystem.initSubSystem()`, because it's not clear what should be used as `path` in those corner cases. It certainly shouldn't throw a NPE :-). It then also more closely matches what hotspot does. Having said that, if `cgroupPath.length < root.length()` it's implied that `cgroupPath.startsWith(root)` is false. Then the only case where it would still be null is when the paths match in lenght, but aren't the same.

I'm not convinced the logic when then cgroup patch starts with the root path, then it should do what it does today. I.e. given `mountpath=/sys/fs/cgroup/memory`, `root=/foo/bar` and `cgroupPath=/foo/bar/baz` then `path=/sys/fs/cgroup/memory/baz`. I've personally not seen such a setup and the code predates me. Considering that the equivalent hotspot code had a bug in this logic since day 1, it doesn't seem very widely used...

The most common cases I know to date are:

1. `root=/`, `cgroupPath=/some`, `mount=/sys/fs/cgroup/controller` => `path=/sys/fs/cgroup/controller/some` (host systems)
2. `root=/foo/bar/baz`, `cgroupPath=/foo/bar/baz`, `mount=/sys/fs/cgroup/controller` => `path=/sys/fs/cgroup/controller` (most container engines)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From lancea at openjdk.java.net  Thu May 12 10:28:07 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 12 May 2022 10:28:07 GMT
Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64
In-Reply-To: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
References: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
Message-ID: <Ko3yptmCM6g64gCPYJQS5aQD_5yQwc47vy26GMdaD50=.7ee2fa92-dfef-404c-bf9a-1c3c614b9e54@github.com>

On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? 
> 
> We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. 
> We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64.

Hi Jai,

Thank you for your efforts with testing and reaching out to Apple.

Given we do not see the issue with the bundled zlib, this is our best path forward for stability on macOS aarch64.

Once we can determine the cause with the help of Apple, we can switch back to the zlib that comes with macOS on this platform.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8675

From aefimov at openjdk.java.net  Thu May 12 10:28:20 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 12 May 2022 10:28:20 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
Message-ID: <LPMTORPLaLz37GHTrbVHhojHEAYWgBpCqFJuFkvH2ig=.afdbdb33-767b-4d44-b7c4-ab55fcfe30d5@github.com>

On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values).
> 
> No test regressions observed in jdk/com/sun/jndi/ldap.
> 
> --
> [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137

Hi @martinuy,

I think this fix is in a good state: code changes look good, the CSR is approved and our CI shows no JNDI test failures related to this change.
As it was mentioned before the only thing we're waiting for is a bug logged for a test addition with a scenario of how issue can be reproduced. If it is not feasible to do that we can proceed without it - I will log a bug and will use a Spring reproducer shared by Carsten (thank you) as a starting point.
Therefore, I'm approving this change.

-------------

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/6043

From ihse at openjdk.java.net  Thu May 12 10:39:56 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 12 May 2022 10:39:56 GMT
Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64
In-Reply-To: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
References: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
Message-ID: <r74topXG_RAMSYy_1cq0hlr6GpAU1i7M0R3q7Sxkb9E=.2d58ad1c-0d7c-43c1-93c8-57c34b462a8a@github.com>

On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? 
> 
> We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. 
> We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64.

LGTM

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8675

From dfuchs at openjdk.java.net  Thu May 12 10:43:06 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 10:43:06 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
Message-ID: <XM-QtZItoREy6Jp95Fewmk32J2F7uszJMp6MV8uaFSs=.4a467006-7276-43b9-855a-64660a8965cc@github.com>

On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values).
> 
> No test regressions observed in jdk/com/sun/jndi/ldap.
> 
> --
> [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6043

From jlahoda at openjdk.java.net  Thu May 12 10:54:16 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 12 May 2022 10:54:16 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v11]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <gWiunLRP5I6LzRaFp8PzTVXg7YNh8jydCMJxYAjNKT4=.68f678bd-0afd-4840-bf79-c4c87b24f01b@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Updating naming to more closely follow the spec: total patterns are renamed to unconditional patterns, unrefined is now unguarded.
 - Case label elements cannot be unguarded if they have a guard of a type different than boolean.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/1101ad46..b0fb8dcd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=09-10

  Stats: 247 lines in 12 files changed: 126 ins; 73 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From mkartashev at openjdk.java.net  Thu May 12 11:00:49 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 12 May 2022 11:00:49 GMT
Subject: RFR: JDK-8285730: unify _WIN32_WINNT settings [v4]
In-Reply-To: <kNgCZx5QuWg5CJ9zdsqsgzzagti0sUYLMONKkPDdMNs=.92fd26d6-cf10-419d-8a6d-2d9a7a3b1d38@github.com>
References: <akJFoun5lg6EsSzQ9eUHbebwZay8562bepX3gEmgMLU=.b3985b6a-a51b-4ebf-9140-5a67f1b07f06@github.com>
 <7_x8MiKFsyiSxn_NRUx9upFmTuD9J-DKDn9eZBNv5oc=.ee030c2c-64d1-4567-bec5-c0188ca73dc8@github.com>
 <Qs8Wm4J27rP2T1O2OJVMQk059XiFUT5I3mpp1bHKRMI=.defc31d7-0e77-4c54-bdba-eac38106647a@github.com>
 <kNgCZx5QuWg5CJ9zdsqsgzzagti0sUYLMONKkPDdMNs=.92fd26d6-cf10-419d-8a6d-2d9a7a3b1d38@github.com>
Message-ID: <Mj4vFn5FlxRR_V24l2_Ct6qqFYM6VCdH7o_U6vmD5L4=.71d84865-ad40-42c2-b39d-4b7dd33c1549@github.com>

On Thu, 12 May 2022 04:25:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change seem to have made this group of declarations obsolete: 
>> `src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h:157` (follow the [link](
>> https://github.com/openjdk/jdk/blob/89de756ffbefac452c7df559e2a4eb50bf71368b/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.h#L157)). Does anyone have plans to drop those? Have any bugs been filed for that? If not, I'll attend to that myself.
>
> @mkartashev  all references to WINVER in the AWT code seem obsolete. Possibly most of the IS_WINxxx usages could also be replaced.

@dholmes-ora @MBaesken Thank you! Filed [JDK-8286634](https://bugs.openjdk.java.net/browse/JDK-8286634).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8428

From ihse at openjdk.java.net  Thu May 12 11:04:08 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 12 May 2022 11:04:08 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4]
In-Reply-To: <cbS0XWcBC0vi8SjU3V3dS4feDWBnMbPjSyCXqoPGcb4=.f2cdf49d-0915-46b1-b436-e3699e94892c@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <hRz0_TToYgAPiC2722w2E0YzZztTp34v74R4OM6A78k=.f5ae0319-cd63-421a-b416-652757587567@github.com>
 <cbS0XWcBC0vi8SjU3V3dS4feDWBnMbPjSyCXqoPGcb4=.f2cdf49d-0915-46b1-b436-e3699e94892c@github.com>
Message-ID: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com>

On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Calculate char offset before realloc()
>
> Thanks for all to review this PR! I think we should separate this issue as following:
> 
> * Suppress warnings
>     * make/modules/java.desktop/lib/Awt2dLibraries.gmk
>     * src/hotspot/share/classfile/bytecodeAssembler.cpp
>     * src/hotspot/share/classfile/classFileParser.cpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>     * src/hotspot/share/opto/memnode.cpp
>     * src/hotspot/share/opto/type.cpp
>     * src/hotspot/share/utilities/compilerWarnings.hpp
>     * src/hotspot/share/utilities/compilerWarnings_gcc.hpp
>     * src/java.base/unix/native/libjli/java_md_common.c
> * Bug fixes
>     * src/java.base/share/native/libjli/java.c
>     * src/java.base/share/native/libjli/parse_manifest.c
>     * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c
> 
> I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library.
> 
> I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only.

@YaSuenag From my PoV this sounds like a good suggestion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From luhenry at openjdk.java.net  Thu May 12 11:12:00 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Thu, 12 May 2022 11:12:00 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v12]
In-Reply-To: <ZFANL7pkofW0OIXkid_UNGGBNw3NUD-IdEknprhYGxQ=.d6359adf-bdad-4272-9430-e7dcbbdaa6d4@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
 <PP7oByBGJce2DZZTe_1W4dtmld2cYUyBj-MiJEo0E58=.904b7b82-0333-4520-918b-0314f0e8fa3a@github.com>
 <ZFANL7pkofW0OIXkid_UNGGBNw3NUD-IdEknprhYGxQ=.d6359adf-bdad-4272-9430-e7dcbbdaa6d4@github.com>
Message-ID: <RU_FFPHSEf4mdN_gsJwCmPjM9ZViH2vmlA7tLs27Glo=.4f65eaee-3137-45d4-948f-11b8c2d28764@github.com>

On Wed, 11 May 2022 19:13:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Fix overlapping registers
>>  - Actually fix h when hashcode is vectorized
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
>>  - Fix h when vectorized for Arrays.hashCode
>>  - Add missing check for AryHashCode node
>>  - Fix some merge conflicts
>>  - Disable Arrays.hashCode intrinsic by default for CI
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
>>  - Some small refactoring: store power_of_31_backwards in the code directly, compact code, and more
>>  - {wip} Generalize string hashcode to Arrays.hashCode
>>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...29dab16b
>
> Looks like you are making great progress.
> 
> Have you thought about ways the intrinsic implementation might be simplified if some code is retained in Java and passed as constant arguments? e.g. table of constants, scalar loop, bounds checks etc, such that the intrinsic primarily focuses on the vectorized code. To some extent that's related to John's point on generalization, and through simplification there may be some generalization.
> 
> For example if there was a general intrinsic that returned a long value (e.g. first 32 bits are the offset in the array to continue processing, the second 32 bits are the current hashcode value) then we could call that from the Java implementations that then proceed with the scalar loop up to the array length. The Java implementation intrinsic would return `(0L | 1L << 32)`.
> 
> Separately it would be nice to consider computing the hash code from the contents of a memory segment, similar to how we added `mismatch` support, but the trick of returning a value that merges the offset and hash code would not work, unless we return the remaining elements to process and that guaranteed to be less than a certain value (or alternatively a relative offset value given an upper bound argument, and performing the intrinsic call in a loop until no progress can be made, which works better for safepoints).
> 
> The `long[]` hashcode is annoying given `(element ^ (element >>> 32))`, but if we simplify the intrinsic maybe we can add back that complexity?

@PaulSandoz yes, keeping the "short" string part in pure Java and switching to an intrinsified/vectorized version for "long" strings is on the next avenue of exploration. I would also put the intrinsic as a runtime stub to avoid unnecessarily increase the size of the calling method unnecessarily. The overhead of the call would be amortised because it would only be called for longer strings anyway.

I haven't given much thoughts to how we could split up the different elements of the algorithm to generalise the approach just yet. I'll give it a try, see how far I can get with it, and keep you updated on my findings.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7700

From mik3hall at gmail.com  Thu May 12 11:17:10 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 12 May 2022 06:17:10 -0500
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
 <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com>
Message-ID: <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com>



> On May 12, 2022, at 4:42 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
>> Some further spelunking reveals the issue. Consider this: 
>> 
>> % otool -s __TEXT __info_plist -v APP_NAME.app/Contents/runtime/Contents/Home/bin/java 
>> ? 
>> <dict> 
>> <key>CFBundleIdentifier</key> 
>> <string>net.java.openjdk.java</string> 
>> ? 
>> </dict> 
>> </plist> 
>> 
>> This is an obscure corner case in the macOS bundle story: A standalone tool, like `java`, which isn?t in a bundle structure, and thus can?t have a standalone `Info.plist` file, can put its information property list in a `__TEXT` / `__info_plist` section within its executable. And it seems that the folks who created your Java runtime did just that. 
>> 
>> Given that, the Mac App Store error is valid: You are trying to submit an executable whose bundle ID matches some existing app. 
>> 
>> To get around this check you?ll need to give `java` a new bundle ID. That?s not easy to do. This `__TEXT` / `__info_plist` section is set up by a linker option (see `-sectcreate` in <x-man-page://1/ld&gt;) <x-man-page://1/ld%3E)> and there?s no good way to modify it after the fact [1]. 

I had read this but possibly didn?t grok the issue myself. If I understand correctly now the conflict isn?t within the application but across applications to some other application that has already been added to the Mac App Store that included the commands with the given CFBundleIdentifier. A solution like including a bundle identifier something like net.java.openjdk.MYAPP.java would be possible at packaging time but not at build time. 
To fix this at build time you would need to generate a name unique to each installed jdk. Including release net.java.openjdk.JDK_RELEASE.java might avoid some conflicts but would still be open to conflict for two applications at the same release. So it can?t be addressed ?before the fact? either. The only thing I am currently thinking of that might work would be include a replaceable part in the identifier. So something like net.java.openjdk.java.XXXXXXXXXXXXXXXXXXXXXX
Where jpackage could include something to change the XXXXX?. to a unique application name. If you don?t change the string size you could probably avoid some of the resizing issues Apple DTS mentions. Whether there is a standard Apple tool to do this I don?t know. 

From sgehwolf at openjdk.java.net  Thu May 12 11:36:46 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 11:36:46 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
In-Reply-To: <Tb2H9w2gDKJ7c4-dlu08OxlxhOvXac4KI_ZPU0bakT8=.1f13223a-8a2c-42a4-bae9-d5f78ed81c10@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <Tb2H9w2gDKJ7c4-dlu08OxlxhOvXac4KI_ZPU0bakT8=.1f13223a-8a2c-42a4-bae9-d5f78ed81c10@github.com>
Message-ID: <WILIeWUVwxUpcuxVnZRdm6iqCWgxn1qX9NRJrjhNQK4=.80206e0f-ad75-4091-a625-e8eaf8563995@github.com>

On Thu, 12 May 2022 06:13:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I just started to look at the code so just one comment for now.

Sure, thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From luhenry at openjdk.java.net  Thu May 12 11:50:27 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Thu, 12 May 2022 11:50:27 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v13]
In-Reply-To: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
Message-ID: <_maS9amwBO2HLjHte1KjTxIc88dD3LcwjFCPWnenZiQ=.0797e708-1945-46dc-903c-9c7fd702c6aa@github.com>

> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
> 
> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
> 
> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
> 
> 
> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
> 
> 
> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
> 
> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf

Ludovic Henry has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Ensure a proper register is used + Slight performance optimizations
 - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
 - Fix overlapping registers
 - Actually fix h when hashcode is vectorized
 - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
 - Fix h when vectorized for Arrays.hashCode
 - Add missing check for AryHashCode node
 - Fix some merge conflicts
 - Disable Arrays.hashCode intrinsic by default for CI
 - Merge branch 'master' of https://github.com/openjdk/jdk into vectorized-stringlatin1-hashcode
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/73c5e993...34b90e84

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7700/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=12
  Stats: 1160 lines in 25 files changed: 1149 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7700.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7700/head:pull/7700

PR: https://git.openjdk.java.net/jdk/pull/7700

From magnus.ihse.bursie at oracle.com  Thu May 12 11:58:59 2022
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 May 2022 13:58:59 +0200
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
 <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com>
 <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com>
Message-ID: <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com>

On 2022-05-12 13:17, Michael Hall wrote:
> I had read this but possibly didn?t grok the issue myself. If I 
> understand correctly now the conflict isn?t within the application but 
> across applications to some other application that has already been 
> added to the Mac App Store that included the commands with the given 
> CFBundleIdentifier. 

Yes, that is indeed how I also interpret this. Presumably, the very 
first developer to submit a jpackaged application to App Store (from 
what I can tell now OpenJDK itself is not present there, which I 
mistakenly believed before) got everything working without troubles, but 
blocked all other developers from submitting their apps.

> A solution like including a bundle identifier something like 
> net.java.openjdk.MYAPP.java would be possible at packaging time but 
> not at build time.
> To fix this at build time you would need to generate a name unique to 
> each installed jdk. Including release 
> net.java.openjdk.JDK_RELEASE.java might avoid some conflicts but would 
> still be open to conflict for two applications at the same release. So 
> it can?t be addressed ?before the fact? either. The only thing I am 
> currently thinking of that might work would be include a replaceable 
> part in the identifier. So something like 
> net.java.openjdk.java.XXXXXXXXXXXXXXXXXXXXXX
> Where jpackage could include something to change the XXXXX?. to a 
> unique application name. If you don?t change the string size you could 
> probably avoid some of the resizing issues Apple DTS mentions. Whether 
> there is a standard Apple tool to do this I don?t know.

As you say, we're a bit in a bind since the java executable needs to be 
created when the JDK is built, but the bundle ID needs to be determined 
when jpackage is run (and a suitable, per-application ID can be 
created), and there is no standard tooling to update the bundle ID after 
build time.

I believe what you are describing is exactly solution #2 suggested by 
the Apple engineer. I don't think that would be horribly difficult to 
achieve, though. Sure, it's a bit of a hack, but not the ugliest I've 
seen in my days. If we go down this route, I suppose we do something 
like this:

1) When building the JDK, we create an additional copy of the java 
executable, and store it with the jdk.jpackage resources. Let's call it 
java.template, for the sake of it. This is identical to the real 
bin/java except for the fact that it contains a different bundle ID, 
with a large enough padding field, like XXXXX...? This way, we don't 
have to mess around with the real java executable for the JDK.

2) At jpackage time, this java.template file is installed instead of 
bin/java, and the padding field is replaced by a unique value. The java 
executable is small (33kB on macOS, currently) so a simple search 
through the binary field for the pattern is likely to work alright. As 
long as there are no checksums being broken, this should be straightforward.

My primary suggestion would to be to use an UUID for the unique ID. They 
are of fixed length, are for all intents and purposes unique and you can 
conjure them up from your hat. (An alternative is that the user needs to 
specify a unique ID, but that is probably a less ideal solution.) 
Presumably, we can have some kind of prefix like "org.openjdk.jpackage." 
before the UUID to make them a bit understandable, if someone where to 
inspect the package metadata.

This seems like a fully workable solution to me. However, I'd really 
like to understand option #1 better, which was: "Package the `java` 
executable in a standard bundle, replacing 
`runtime/Contents/Home/bin/java` with a symlink to that."

I don't know what a "standard bundle" is, or how you would go around to 
package the java executable in one. But on the surface, it sounds much 
nicer than binary editing.

I also don't understand if that means that the standard bundle needs to 
be created at jpackage time, so it gives us the chance to set a proper 
ID, or if the standard bundle can be created at build time, and then the 
existence of this bundle just makes Apple avoid the bundle ID collision 
checks. Or if I'm just misunderstanding it all...

/Magnus

From mik3hall at gmail.com  Thu May 12 12:10:24 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 12 May 2022 07:10:24 -0500
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
 <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com>
 <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com>
 <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com>
Message-ID: <ED86C05F-4A16-43C1-9AB5-CCF6F1CD59A0@gmail.com>



> 
> My primary suggestion would to be to use an UUID for the unique ID. They are of fixed length, are for all intents and purposes unique and you can conjure them up from your hat. (An alternative is that the user needs to specify a unique ID, but that is probably a less ideal solution.) Presumably, we can have some kind of prefix like "org.openjdk.jpackage." before the UUID to make them a bit understandable, if someone where to inspect the package metadata.e 

I was thinking jpackage would change the XXX to app name but a fixed size unique field would probably be better.
> 
> This seems like a fully workable solution to me. However, I'd really like to understand option #1 better, which was: "Package the `java` executable in a standard bundle, replacing `runtime/Contents/Home/bin/java` with a symlink to that."
> 
> I don't know what a "standard bundle" is, or how you would go around to package the java executable in one. But on the surface, it sounds much nicer than binary editing.
> 
> I also don't understand if that means that the standard bundle needs to be created at jpackage time, so it gives us the chance to set a proper ID, or if the standard bundle can be created at build time, and then the existence of this bundle just makes Apple avoid the bundle ID collision checks. Or if I'm just misunderstanding it all...
> 
> /Magnus

I may again not understanding but I was thinking they were talking about something like symlinks to a machine installed JDK and this seemed to me to defeat some of the purpose of embedding the jdk. But he could be thinking else. Something external to the application anyhow it seemed.



From sgehwolf at openjdk.java.net  Thu May 12 12:10:51 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 12:10:51 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v16]
In-Reply-To: <_fy0_qvRPy9OmYxuNLe56sP2ycIyhEUaUEgJ3uV2rOs=.dcd42c1e-ee38-44f8-a1bd-093ed2c14d58@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <_fy0_qvRPy9OmYxuNLe56sP2ycIyhEUaUEgJ3uV2rOs=.dcd42c1e-ee38-44f8-a1bd-093ed2c14d58@github.com>
Message-ID: <l2hnaWIgQHl7uapWB60Wv6sXzC1aZncljEaCLxsVRCI=.653a8643-549e-4d0d-bcfe-bf20b46ec11d@github.com>

On Thu, 12 May 2022 09:50:39 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add swap method

This looks good. I think the only thing missing is a test for the JDK side. Perhaps write one using the `OperatingSystemMXBean`'s `getTotalSwapSpaceSize()` method within a container with `--memory=200m --memory-swap=250m` and using `--memory-swappiness=0`. You could use `test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java` and `CheckOperatingSystemMXBean.java` as a model. Again a cgroupsv1 specific test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From mcimadamore at openjdk.java.net  Thu May 12 12:12:55 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 May 2022 12:12:55 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <vO8ppClc_A5MhswLQXuTi-T2_3RAoTg6X69O1sbQVI8=.15e3f5c1-7bed-4d73-a703-e3737b9f3a4a@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
 <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
 <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>
 <T73dHwsxmGWzDhJzzaLzEkOpsi6LB7jHBwcBI-JTJlY=.3929d080-0ae2-4645-88db-f5dfa8f0e855@github.com>
 <AIN9VRXcDj-YKtSkychFW7_ZqXdx3AsWmeMnvzJchl8=.680b9133-929d-4a47-809a-2a654a94bf26@github.com>
 <WCNDNQabM_3gZBaog255y0LSokj044con0d23ZeQ7hA=.cfae3ed7-b420-47fc-bf73-f7f65cddf385@github.com>
 <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com>
 <vO8ppClc_A5MhswLQXuTi-T2_3RAoTg6X69
 O1sbQVI8=.15e3f5c1-7bed-4d73-a703-e3737b9f3a4a@github.com>
Message-ID: <i3sR3qKBIRAlzLMcpbq7kgWfv7b2T9O-KCPXlEljb-0=.fe5edce0-91fb-4549-a8e1-f36cfa549ddc@github.com>

On Thu, 12 May 2022 09:24:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated.

My understanding is that if they materialize while we're executing the upcall Java code, if that code has a try/catch block, we will go there, rather than crash the VM.

In other words, IMHO the only problem with async exception is if they occur _after_ the Java user code has completed, because that will crash the Java adapter, this preventing it from returning to native call cleanly.

So, either we disable async exceptions during that phase (e.g. after user code has executed, but before we return back to native code), or we just punt and stop. Since this seems like a corner^3 case, and since there are also other issue with upcalls that can occur if other threads do not cooperate (e.g. an upcall can get stuck into an infinite safepoint if the VM exits while an async native thread runs the upcall), and given that obtaining a linker is a restricted operation anyway, I don't think we should bend over backwards to try to add 1% more safety to something that's unavoidably sharp anyways.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From luhenry at openjdk.java.net  Thu May 12 12:14:49 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Thu, 12 May 2022 12:14:49 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v14]
In-Reply-To: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
Message-ID: <Kzoo-86lD3frnSC7QG4g7Vs-NMn69QemAB6piLkyGQ8=.f2fe2d84-9d71-4ab3-a38c-13583b944f43@github.com>

> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text.
> 
> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1].
> 
> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
> 
> 
> Benchmark                                        (size)  Mode  Cnt     Score    Error  Units
> StringHashCode.Algorithm.scalarLatin1                 0  avgt   25     2.111 ?  0.210  ns/op
> StringHashCode.Algorithm.scalarLatin1                 1  avgt   25     3.500 ?  0.127  ns/op
> StringHashCode.Algorithm.scalarLatin1                10  avgt   25     7.001 ?  0.099  ns/op
> StringHashCode.Algorithm.scalarLatin1               100  avgt   25    61.285 ?  0.444  ns/op
> StringHashCode.Algorithm.scalarLatin1              1000  avgt   25   628.995 ?  0.846  ns/op
> StringHashCode.Algorithm.scalarLatin1             10000  avgt   25  6307.990 ?  4.071  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       0  avgt   25     2.358 ?  0.092  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16       1  avgt   25     3.631 ?  0.159  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16      10  avgt   25     7.049 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16     100  avgt   25    33.626 ?  1.218  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16    1000  avgt   25   317.811 ?  1.225  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled16   10000  avgt   25  3212.333 ? 14.621  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        0  avgt   25     2.356 ?  0.097  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8        1  avgt   25     3.630 ?  0.158  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8       10  avgt   25     8.724 ?  0.065  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8      100  avgt   25    32.402 ?  0.019  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8     1000  avgt   25   321.949 ?  0.251  ns/op
> StringHashCode.Algorithm.scalarLatin1Unrolled8    10000  avgt   25  3202.083 ?  1.667  ns/op
> StringHashCode.Algorithm.scalarUTF16                  0  avgt   25     2.135 ?  0.191  ns/op
> StringHashCode.Algorithm.scalarUTF16                  1  avgt   25     5.202 ?  0.362  ns/op
> StringHashCode.Algorithm.scalarUTF16                 10  avgt   25    11.105 ?  0.112  ns/op
> StringHashCode.Algorithm.scalarUTF16                100  avgt   25    75.974 ?  0.702  ns/op
> StringHashCode.Algorithm.scalarUTF16               1000  avgt   25   716.429 ?  3.290  ns/op
> StringHashCode.Algorithm.scalarUTF16              10000  avgt   25  7095.459 ? 43.847  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        0  avgt   25     2.381 ?  0.038  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16        1  avgt   25     5.268 ?  0.422  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16       10  avgt   25    11.248 ?  0.178  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16      100  avgt   25    52.966 ?  0.089  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16     1000  avgt   25   450.912 ?  1.834  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled16    10000  avgt   25  4403.988 ?  2.927  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         0  avgt   25     2.401 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8         1  avgt   25     5.091 ?  0.396  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8        10  avgt   25    12.801 ?  0.189  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8       100  avgt   25    52.068 ?  0.032  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8      1000  avgt   25   453.270 ?  0.340  ns/op
> StringHashCode.Algorithm.scalarUTF16Unrolled8     10000  avgt   25  4433.112 ?  2.699  ns/op
> 
> 
> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact.
> 
> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf

Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision:

  Reenable SpecialArraysHashCode by default

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7700/files
  - new: https://git.openjdk.java.net/jdk/pull/7700/files/34b90e84..5d862665

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7700.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7700/head:pull/7700

PR: https://git.openjdk.java.net/jdk/pull/7700

From alanb at openjdk.java.net  Thu May 12 12:27:06 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 12 May 2022 12:27:06 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec
In-Reply-To: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
Message-ID: <2ianG0Dk2e14SluE2qzVa3tos1_Wcj2CyT8ZBwtMMX8=.9bb5a89b-b577-43a5-8ff9-5d2c280156a8@github.com>

On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.
> 
> The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605

src/java.base/share/classes/java/io/InputStream.java line 177:

> 175:      *
> 176:      * @apiNote
> 177:      * A subclass must provide an implementation of this method.

Is this sentence useful to keep? The method is abstract so a concrete implementation has to implement it. On the other other hand, an abstract subclass does not need to implement it.

src/java.base/share/classes/java/io/InputStream.java line 688:

> 686:      * @implSpec
> 687:      * The {@code mark} method of {@code InputStream} does
> 688:      * nothing.

Minor nit but the line break can be removed so that "nothing" is on the same line.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8663

From erikj at openjdk.java.net  Thu May 12 12:44:52 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 12 May 2022 12:44:52 GMT
Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64
In-Reply-To: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
References: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
Message-ID: <-hqvmnHiJUolmAt5JCObYbHwkCGOmwdGNMTRhc1JPAU=.aed971e3-7581-4de7-b14f-6a358e08e98e@github.com>

On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? 
> 
> We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. 
> We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8675

From dholmes at openjdk.java.net  Thu May 12 13:12:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 12 May 2022 13:12:04 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v10]
In-Reply-To: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <JcFdQwOApAPaDk0YR_iAJLZ-KUBXT3KPz0LJaJU0XCA=.b095806e-5e87-4d52-a17b-762756169f2c@github.com>
 <xFXj9bYGLGV98x1bn-FiLLOcLFHWS7R3HIEGEuxkd20=.85db1338-1f52-4be7-a778-3e3ec38c0d94@github.com>
 <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com>
Message-ID: <VFp0PM84xzVbPJObh4b1YPGX_0PIo9FQYJfJcnuct7k=.d929d0fc-bd23-4a56-9ffb-7871071c0b79@github.com>

On Thu, 12 May 2022 08:23:11 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.
>>> 3:  * Copyright (c) 2019, 2021, Arm Limited. All rights reserved.
>> 
>> Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example.
>> Also it is 2022. :)
>
> I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo.

That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From erik.joelsson at oracle.com  Thu May 12 13:25:35 2022
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 12 May 2022 06:25:35 -0700
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
 <9e1f32b1-08d1-5cba-3d29-fd760d7202ac@oracle.com>
 <1BD7D7E5-85AF-48C9-9E66-7308F11AA286@gmail.com>
 <70625b0b-6414-28d0-bc99-7302bd346ade@oracle.com>
Message-ID: <edb53afe-0f47-cfbc-ee8f-900960a93d7f@oracle.com>


On 2022-05-12 04:58, Magnus Ihse Bursie wrote:
> On 2022-05-12 13:17, Michael Hall wrote:
>> A solution like including a bundle identifier something like 
>> net.java.openjdk.MYAPP.java would be possible at packaging time but 
>> not at build time.
>> To fix this at build time you would need to generate a name unique to 
>> each installed jdk. Including release 
>> net.java.openjdk.JDK_RELEASE.java might avoid some conflicts but 
>> would still be open to conflict for two applications at the same 
>> release. So it can?t be addressed ?before the fact? either. The only 
>> thing I am currently thinking of that might work would be include a 
>> replaceable part in the identifier. So something like 
>> net.java.openjdk.java.XXXXXXXXXXXXXXXXXXXXXX
>> Where jpackage could include something to change the XXXXX?. to a 
>> unique application name. If you don?t change the string size you 
>> could probably avoid some of the resizing issues Apple DTS mentions. 
>> Whether there is a standard Apple tool to do this I don?t know.
>
> As you say, we're a bit in a bind since the java executable needs to 
> be created when the JDK is built, but the bundle ID needs to be 
> determined when jpackage is run (and a suitable, per-application ID 
> can be created), and there is no standard tooling to update the bundle 
> ID after build time.
>
> I believe what you are describing is exactly solution #2 suggested by 
> the Apple engineer. I don't think that would be horribly difficult to 
> achieve, though. Sure, it's a bit of a hack, but not the ugliest I've 
> seen in my days. If we go down this route, I suppose we do something 
> like this:
>
> 1) When building the JDK, we create an additional copy of the java 
> executable, and store it with the jdk.jpackage resources. Let's call 
> it java.template, for the sake of it. This is identical to the real 
> bin/java except for the fact that it contains a different bundle ID, 
> with a large enough padding field, like XXXXX...? This way, we don't 
> have to mess around with the real java executable for the JDK.

Aren't we embedding this bundle ID in every launcher, so you would need 
a <launcher>.template for each possible launcher that could be included 
in an app?

What I think we need to do is first evaluate if we actually need to 
embed this bundle ID in the executables at all, or rather, what would 
the consequences be if we didn't. My understanding is that we only do 
this to be able to run them outside of a bundle directory structure, but 
this would need some pretty thorough testing of course. If we are to 
generate a special set of launchers for jpackage, maybe all we need to 
do is not embed any bundle ID in them, as they are meant to only be used 
within a jpackaged app, so they should be covered by Info.plist files 
anyway.

/Erik

From duke at openjdk.java.net  Thu May 12 13:32:03 2022
From: duke at openjdk.java.net (xpbob)
Date: Thu, 12 May 2022 13:32:03 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v17]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <2Kub5hfCrqkdUDDv3riUuKI37DVYEvIWWrFXNm8iv3g=.c0b6e778-fb2d-4c98-bd2d-f4e775d26c54@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  add test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/296a409e..93bc46a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=15-16

  Stats: 36 lines in 1 file changed: 29 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From swpalmer at gmail.com  Thu May 12 13:34:19 2022
From: swpalmer at gmail.com (Scott Palmer)
Date: Thu, 12 May 2022 09:34:19 -0400
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <ED86C05F-4A16-43C1-9AB5-CCF6F1CD59A0@gmail.com>
References: <ED86C05F-4A16-43C1-9AB5-CCF6F1CD59A0@gmail.com>
Message-ID: <88CD901E-5E0F-4400-96E0-4094AAB62C95@gmail.com>



> On May 12, 2022, at 8:10 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> ?
> 
>> 
>> My primary suggestion would to be to use an UUID for the unique ID. They are of fixed length, are for all intents and purposes unique and you can conjure them up from your hat. (An alternative is that the user needs to specify a unique ID, but that is probably a less ideal solution.) Presumably, we can have some kind of prefix like "org.openjdk.jpackage." before the UUID to make them a bit understandable, if someone where to inspect the package metadata.e 
> 
> I was thinking jpackage would change the XXX to app name but a fixed size unique field would probably be better.
>> 
>> This seems like a fully workable solution to me. However, I'd really like to understand option #1 better, which was: "Package the `java` executable in a standard bundle, replacing `runtime/Contents/Home/bin/java` with a symlink to that."
>> 
>> I don't know what a "standard bundle" is, or how you would go around to package the java executable in one. But on the surface, it sounds much nicer than binary editing.
>> 
>> I also don't understand if that means that the standard bundle needs to be created at jpackage time, so it gives us the chance to set a proper ID, or if the standard bundle can be created at build time, and then the existence of this bundle just makes Apple avoid the bundle ID collision checks. Or if I'm just misunderstanding it all...
>> 
>> /Magnus
> 
> I may again not understanding but I was thinking they were talking about something like symlinks to a machine installed JDK and this seemed to me to defeat some of the purpose of embedding the jdk. But he could be thinking else. Something external to the application anyhow it seemed.
> 

I thought they meant something like the embedded JDK would be like a framework bundle. Since the framework is expected to be the same in multiple apps it would be excluded from the duplicate id check. (I think that is related to the older bug that the Apple guy thought might have come back.)

Scott

From sgehwolf at openjdk.java.net  Thu May 12 13:38:00 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 13:38:00 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v17]
In-Reply-To: <2Kub5hfCrqkdUDDv3riUuKI37DVYEvIWWrFXNm8iv3g=.c0b6e778-fb2d-4c98-bd2d-f4e775d26c54@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <2Kub5hfCrqkdUDDv3riUuKI37DVYEvIWWrFXNm8iv3g=.c0b6e778-fb2d-4c98-bd2d-f4e775d26c54@github.com>
Message-ID: <ZTn_8LQOs5vJSXti7Opk21lBfmo2o5Z3DkdiMc9GjkE=.38fb5990-1e26-4475-9e3f-6b0fa4709ebf@github.com>

On Thu, 12 May 2022 13:32:03 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

LGTM. Consider a better name for the test :)

test/hotspot/jtreg/containers/docker/TestMemoryWithCgroupV1.java line 90:

> 88:     }
> 89: 
> 90:     private static void testOperatingSystemMXBeanAwareness(String memoryAllocation, String swapAllocation,

Please use a more telling name for this. Perhaps this? `testOSBeanSwappinessMemory`.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Thu May 12 13:38:01 2022
From: duke at openjdk.java.net (xpbob)
Date: Thu, 12 May 2022 13:38:01 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v17]
In-Reply-To: <2Kub5hfCrqkdUDDv3riUuKI37DVYEvIWWrFXNm8iv3g=.c0b6e778-fb2d-4c98-bd2d-f4e775d26c54@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <2Kub5hfCrqkdUDDv3riUuKI37DVYEvIWWrFXNm8iv3g=.c0b6e778-fb2d-4c98-bd2d-f4e775d26c54@github.com>
Message-ID: <Ef0ri7AvTWyJv7p4cm4fx7UfUq7kr4Dn2bfU3PvnpII=.14bf262c-ab12-4989-afb7-94d7878dc1c6@github.com>

On Thu, 12 May 2022 13:32:03 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

Thanks for review.
@jerboaa
Added test in TestMemoryWithCgroupV1

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Thu May 12 13:46:11 2022
From: duke at openjdk.java.net (xpbob)
Date: Thu, 12 May 2022 13:46:11 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v18]
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <8rNf17Q6js-lYaRIA31S6ft-GB2fYNfpEJvNja2Blc4=.d803b76c-c43f-4569-a8aa-16fc496bdad6@github.com>

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

xpbob has updated the pull request incrementally with one additional commit since the last revision:

  rename method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8285/files
  - new: https://git.openjdk.java.net/jdk/pull/8285/files/93bc46a6..584488f9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8285&range=16-17

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8285.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8285/head:pull/8285

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Thu May 12 13:46:13 2022
From: duke at openjdk.java.net (xpbob)
Date: Thu, 12 May 2022 13:46:13 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v17]
In-Reply-To: <2Kub5hfCrqkdUDDv3riUuKI37DVYEvIWWrFXNm8iv3g=.c0b6e778-fb2d-4c98-bd2d-f4e775d26c54@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <2Kub5hfCrqkdUDDv3riUuKI37DVYEvIWWrFXNm8iv3g=.c0b6e778-fb2d-4c98-bd2d-f4e775d26c54@github.com>
Message-ID: <s9S7_iuKZR66LweXX38hiilKkXAHxLzrJbcNgmkGAUk=.b014c9ba-e21f-4eda-a5b3-035cad91e56e@github.com>

On Thu, 12 May 2022 13:32:03 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test

Thanks for review.
@jerboaa
The expression is clearer after the change

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From ngasson at openjdk.java.net  Thu May 12 13:59:11 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 12 May 2022 13:59:11 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v10]
In-Reply-To: <VFp0PM84xzVbPJObh4b1YPGX_0PIo9FQYJfJcnuct7k=.d929d0fc-bd23-4a56-9ffb-7871071c0b79@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <JcFdQwOApAPaDk0YR_iAJLZ-KUBXT3KPz0LJaJU0XCA=.b095806e-5e87-4d52-a17b-762756169f2c@github.com>
 <xFXj9bYGLGV98x1bn-FiLLOcLFHWS7R3HIEGEuxkd20=.85db1338-1f52-4be7-a778-3e3ec38c0d94@github.com>
 <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com>
 <VFp0PM84xzVbPJObh4b1YPGX_0PIo9FQYJfJcnuct7k=.d929d0fc-bd23-4a56-9ffb-7871071c0b79@github.com>
Message-ID: <NTmZJhBUST6_v3tVLqoh01V6MUrUWU1VH9YnzD6ZVjo=.d42d5a4d-4685-4547-ae02-4daf4877bee2@github.com>

On Thu, 12 May 2022 13:07:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo.
>
> That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright.

I think the Arm line can be updated to 2022 at the same time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From stuefe at openjdk.java.net  Thu May 12 14:05:57 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 12 May 2022 14:05:57 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
In-Reply-To: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
Message-ID: <PT5BLg7JAwHZRRhw3c1HV53IHWBiuf6NFUAOMYYQTLI=.f91bbf3c-569b-49d8-85f1-62a0f8c62589@github.com>

On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
> 
> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
> 
> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
> 
> Testing:
> - [x] Added unit tests
> - [x] GHA
> - [x] Container tests on cgroups v1 Linux. Continue to pass

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 113:

> 111:           }
> 112:           buf[MAXPATHLEN-1] = '\0';
> 113:           _path = os::strdup(buf);

I think this code can be simplified a lot with stringStream and without strtok, so no need for fixed buffers (which may fail with longer path names) and no need for writable string copies on the stack.

Something like this:

stringStream ss;
ss.print_raw(_mount_point);
const char* p1 = _root;
const char* p2 = cgroup_path;
int last_matching_dash_pos = -1;
for (int i = 0; *p1 == *p2 && *p1 != 0; i ++) {
	if (*p1 == '/') {
		last_matching_dash_pos = i;
	}
        p1++; p2++;
}
ss.print_raw(_root, last_matching_dash_pos);
// Now use ss.base() to access the assembled string

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From alanb at openjdk.java.net  Thu May 12 14:12:02 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 12 May 2022 14:12:02 GMT
Subject: RFR: 8286560: Remove user parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>
References: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>
Message-ID: <NPEyR1B0lyWvAe7_IpvfX_YvcjEORCNjVB5XWApAfUQ=.3242177b-9598-4b46-96cd-1be23c351e39@github.com>

On Wed, 11 May 2022 23:08:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/jdk/internal/perf/Perf.java line 246:

> 244:      */
> 245:     private native ByteBuffer attach0(int lvmid)
> 246:                    throws IllegalArgumentException, IOException;

You can drop the "throws IllegalArgumentException" here if you want, it's not needed as it's a runtime exception.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8669

From weijun at openjdk.java.net  Thu May 12 14:18:59 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 12 May 2022 14:18:59 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v3]
In-Reply-To: <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
Message-ID: <_iORn6NU_sX0ffx8xSNHkigSlplyKN58kEJ7pIcxhUo=.79b191fd-edde-40d7-a28c-e6bc82a8e28a@github.com>

On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282662: Revert dubious changes in MethodType

src/java.base/share/classes/sun/security/validator/EndEntityChecker.java line 119:

> 117:     // TLS key exchange algorithms requiring keyEncipherment key usage
> 118:     private static final Collection<String> KU_SERVER_ENCRYPTION =
> 119:         Arrays.asList("RSA");

I understand that you haven't modified the `KU_SERVER_KEY_AGREEMENT` on line 122 because it has 4 elements. However, these 2 nearby lines using different styles look a little strange to me. Why restrict the number to 0, 1, and 2? If we have defined methods with up to 9 arguments, does that mean the new type is suitable for 9 elements?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From jvernee at openjdk.java.net  Thu May 12 14:53:03 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 14:53:03 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v12]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <wv1md1wkaNos3X3dlNX8ot4rij_GiviQhn1DyaTXeEw=.dbcabba3-f420-4c15-9f84-646cef004313@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Update Oracle copyright years

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/1c04a42e..9a7bb6bb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=10-11

  Stats: 70 lines in 70 files changed: 0 ins; 0 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Thu May 12 15:03:05 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 15:03:05 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v10]
In-Reply-To: <NTmZJhBUST6_v3tVLqoh01V6MUrUWU1VH9YnzD6ZVjo=.d42d5a4d-4685-4547-ae02-4daf4877bee2@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <JcFdQwOApAPaDk0YR_iAJLZ-KUBXT3KPz0LJaJU0XCA=.b095806e-5e87-4d52-a17b-762756169f2c@github.com>
 <xFXj9bYGLGV98x1bn-FiLLOcLFHWS7R3HIEGEuxkd20=.85db1338-1f52-4be7-a778-3e3ec38c0d94@github.com>
 <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com>
 <VFp0PM84xzVbPJObh4b1YPGX_0PIo9FQYJfJcnuct7k=.d929d0fc-bd23-4a56-9ffb-7871071c0b79@github.com>
 <NTmZJhBUST6_v3tVLqoh01V6MUrUWU1VH9YnzD6ZVjo=.d42d5a4d-4685-4547-ae02-4daf4877bee2@github.com>
Message-ID: <LBoqqnHnAvQ2t98okTIhCoSdsjARJU4KwCJ9mKLWzTg=.2c94bd81-759c-4de2-957c-c4620c3b8e7e@github.com>

On Thu, 12 May 2022 13:55:20 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright.
>
> I think the Arm line can be updated to 2022 at the same time.

I've updated all the Oracle copyright years in the files touched by this PR.

@nick-arm If you wouldn't mind, could you use the "Add a suggestion" feature (the +/- button when leaving a review comment) to suggest copyright year updates to the relevant files (I think it's just foreign_globals_aarch64.cpp and universalUpcallHandler_aarch64.cpp).

That way, when I accept those suggestions, an automatic commit will be made with you as the commit co-author, and it's even clearer that I'm making that change on your behalf. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Thu May 12 15:07:57 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 15:07:57 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v13]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <Us3m815Ac_IFXxgEfYuS5GhLOmjNWetwybIKFWp4VP8=.9685ec38-7a3b-433f-a4b1-ee3ccb8047a9@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Missed 2 years

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/9a7bb6bb..8100e0a7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=11-12

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From ngasson at openjdk.java.net  Thu May 12 15:08:01 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 12 May 2022 15:08:01 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v12]
In-Reply-To: <wv1md1wkaNos3X3dlNX8ot4rij_GiviQhn1DyaTXeEw=.dbcabba3-f420-4c15-9f84-646cef004313@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <wv1md1wkaNos3X3dlNX8ot4rij_GiviQhn1DyaTXeEw=.dbcabba3-f420-4c15-9f84-646cef004313@github.com>
Message-ID: <JBM4IZaGuekVhkzO1ymBiL0lfI9Jkn9b3XDGMMW8bmI=.a76cc136-7fbf-4f66-b12d-7f0ab7aa925b@github.com>

On Thu, 12 May 2022 14:53:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
>> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
>> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
>> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Oracle copyright years

src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3:

> 1: /*
> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2019, 2021, Arm Limited. All rights reserved.

Suggestion:

 * Copyright (c) 2019, 2022, Arm Limited. All rights reserved.

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 3:

> 1: /*
> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2019, 2021, Arm Limited. All rights reserved.

Suggestion:

 * Copyright (c) 2019, 2022, Arm Limited. All rights reserved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From mullan at openjdk.java.net  Thu May 12 15:11:02 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 12 May 2022 15:11:02 GMT
Subject: RFR: 8286594: (zipfs) Improvements after JDK-8251329
In-Reply-To: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com>
References: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com>
Message-ID: <_uQj3PWsPqeX42kZya_w-wVyE0Ir8LGVY1fVJdOx97o=.491ece42-760d-4644-82ba-54f220a518b8@github.com>

On Wed, 11 May 2022 15:32:38 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements.
> 
> It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode::nameAsString to return the node name as a String.

A more descriptive title for the bug report would be helpful.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8655

From jvernee at openjdk.java.net  Thu May 12 15:16:08 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 15:16:08 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v14]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <bJRAgoud2E2ME63_YmqutRqTNG2_mWbtjCYRZPg73vs=.29a88925-7b4b-482c-a0df-0856bb370ba8@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Apply copyright year updates per request of @nick-arm
  
  Co-authored-by: Nick Gasson <nick.gasson at arm.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/8100e0a7..0f49ff0b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=12-13

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Thu May 12 15:16:10 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 15:16:10 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v10]
In-Reply-To: <NTmZJhBUST6_v3tVLqoh01V6MUrUWU1VH9YnzD6ZVjo=.d42d5a4d-4685-4547-ae02-4daf4877bee2@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <JcFdQwOApAPaDk0YR_iAJLZ-KUBXT3KPz0LJaJU0XCA=.b095806e-5e87-4d52-a17b-762756169f2c@github.com>
 <xFXj9bYGLGV98x1bn-FiLLOcLFHWS7R3HIEGEuxkd20=.85db1338-1f52-4be7-a778-3e3ec38c0d94@github.com>
 <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com>
 <VFp0PM84xzVbPJObh4b1YPGX_0PIo9FQYJfJcnuct7k=.d929d0fc-bd23-4a56-9ffb-7871071c0b79@github.com>
 <NTmZJhBUST6_v3tVLqoh01V6MUrUWU1VH9YnzD6ZVjo=.d42d5a4d-4685-4547-ae02-4daf4877bee2@github.com>
Message-ID: <oBJ_PCIEktRswB_xvj-M4UEyon4Va-RTMQdgvfGk1aQ=.e5eb5c4d-5c78-433f-9aa5-358d9efb9efa@github.com>

On Thu, 12 May 2022 13:55:20 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright.
>
> I think the Arm line can be updated to 2022 at the same time.

@nick-arm Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From psandoz at openjdk.java.net  Thu May 12 15:38:57 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 12 May 2022 15:38:57 GMT
Subject: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1,
 and Arrays polynomial hash loops [v12]
In-Reply-To: <RU_FFPHSEf4mdN_gsJwCmPjM9ZViH2vmlA7tLs27Glo=.4f65eaee-3137-45d4-948f-11b8c2d28764@github.com>
References: <FWcO68jzFpwSy0GlO70BIYgdUBK6Nhb4PhlVUik8gQQ=.1b51ef51-4450-4311-bcf4-ae18cc3a7f74@github.com>
 <PP7oByBGJce2DZZTe_1W4dtmld2cYUyBj-MiJEo0E58=.904b7b82-0333-4520-918b-0314f0e8fa3a@github.com>
 <ZFANL7pkofW0OIXkid_UNGGBNw3NUD-IdEknprhYGxQ=.d6359adf-bdad-4272-9430-e7dcbbdaa6d4@github.com>
 <RU_FFPHSEf4mdN_gsJwCmPjM9ZViH2vmlA7tLs27Glo=.4f65eaee-3137-45d4-948f-11b8c2d28764@github.com>
Message-ID: <qduFySEnfujWC8mZqtTAeeFvyuSBo7gBAry51uliyi4=.66e2bc98-eee2-4f5a-9a84-7312719d4751@github.com>

On Thu, 12 May 2022 11:08:10 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Looks like you are making great progress.
>> 
>> Have you thought about ways the intrinsic implementation might be simplified if some code is retained in Java and passed as constant arguments? e.g. table of constants, scalar loop, bounds checks etc, such that the intrinsic primarily focuses on the vectorized code. To some extent that's related to John's point on generalization, and through simplification there may be some generalization.
>> 
>> For example if there was a general intrinsic that returned a long value (e.g. first 32 bits are the offset in the array to continue processing, the second 32 bits are the current hashcode value) then we could call that from the Java implementations that then proceed with the scalar loop up to the array length. The Java implementation intrinsic would return `(0L | 1L << 32)`.
>> 
>> Separately it would be nice to consider computing the hash code from the contents of a memory segment, similar to how we added `mismatch` support, but the trick of returning a value that merges the offset and hash code would not work, unless we return the remaining elements to process and that guaranteed to be less than a certain value (or alternatively a relative offset value given an upper bound argument, and performing the intrinsic call in a loop until no progress can be made, which works better for safepoints).
>> 
>> The `long[]` hashcode is annoying given `(element ^ (element >>> 32))`, but if we simplify the intrinsic maybe we can add back that complexity?
>
> @PaulSandoz yes, keeping the "short" string part in pure Java and switching to an intrinsified/vectorized version for "long" strings is on the next avenue of exploration. I would also put the intrinsic as a runtime stub to avoid unnecessarily increase the size of the calling method unnecessarily. The overhead of the call would be amortised because it would only be called for longer strings anyway.
> 
> I haven't given much thoughts to how we could split up the different elements of the algorithm to generalise the approach just yet. I'll give it a try, see how far I can get with it, and keep you updated on my findings.

@luhenry ok, we took a similar approach to the mismatch intrinsic, carefully analyzing the threshold by which the intrinsic would be called.

My suggestion would be to follow that approach further and head towards an internal intrinsic perhaps with this signature:

@IntrinsicCandidate
static long hashCode(Class<T> eType, Object base, long offset, int length /* in bytes * /) {
  return 0 | (1L << 32); // or perhaps just return 0
}  
``` 

Then on a further iteration try and pass the polynomial constant and table of powers (stable array) as arguments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7700

From mcimadamore at openjdk.java.net  Thu May 12 15:45:01 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 May 2022 15:45:01 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:

 - Merge branch 'master' into foreign-preview
 - Merge branch 'master' into foreign-preview
 - Fix crashes in heap segment benchmarks due to misaligned access
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Add tests for loaderLookup/restricted method corner cases
 - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
   * Tweak restricted method check to work when there's no caller class
 - Tweak examples in SymbolLookup javadoc
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7888/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=44
  Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7888.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888

PR: https://git.openjdk.java.net/jdk/pull/7888

From bpb at openjdk.java.net  Thu May 12 15:48:47 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 12 May 2022 15:48:47 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF [v2]
In-Reply-To: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
Message-ID: <h-1cJi4Mp30kp7L-FiEhnfqecif6Z9Vuc3qVqXfo6Q0=.2498b98c-c495-4bc8-9da2-d135b37d1fd1@github.com>

> Modify the specification of `SequenceInputStream.read(byte[],int,int)` to indicate that `-1` is returned at the EOF of the last stream even if `len` is zero.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8286200: Change @throws IOOBE clause of read(byte[],int,int) to better match specification verbiage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8664/files
  - new: https://git.openjdk.java.net/jdk/pull/8664/files/b5883b84..7582dbff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8664&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8664&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8664.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8664/head:pull/8664

PR: https://git.openjdk.java.net/jdk/pull/8664

From bpb at openjdk.java.net  Thu May 12 15:48:48 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 12 May 2022 15:48:48 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF
In-Reply-To: <HIcmZHW9p-POTlA5EGDM8QSkK7Jqrp68w2xNDdZNNQs=.06c9803e-7981-4732-aae3-4d9e234b9b79@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
 <HIcmZHW9p-POTlA5EGDM8QSkK7Jqrp68w2xNDdZNNQs=.06c9803e-7981-4732-aae3-4d9e234b9b79@github.com>
Message-ID: <e9if1319F-OPIUoQXs41bLYBYTsNuIU92r-dpyLbStc=.f7281de3-326b-4786-96e1-01a2db201b55@github.com>

On Thu, 12 May 2022 08:41:47 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Also, in the current implementation, when the end of the last contained stream has been reached and `-1` is returned, none of the arguments is checked, so a caller can pass `null` for `b` or out of bounds indices `off` and `len`. This is at odd with the `@throws` clauses.

Resolved by commit 7582dbff416e1fb164cfe924c128eb5ee73084f4.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8664

From mcimadamore at openjdk.java.net  Thu May 12 15:51:00 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 May 2022 15:51:00 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v34]
In-Reply-To: <HVsG_LCCzlUo1f-0ZMKlCGM047qK2h9Klo3NGEPhfaM=.5717ef82-7868-43e7-bb12-9f64c434455c@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <TrgodOJnd7PvUKRq57FfJP1CVrox4OPjD3fdWsQKvDU=.08f8a628-ab0b-43ba-a13d-3000d069c94f@github.com>
 <eKsZc48hwSbNzDv1iR9NoUPihAVyFMlv62fo_CPkmFo=.639bba4f-2864-47a0-addf-38ff659f36aa@github.com>
 <ev2fhY31U-E7cbjQ1P6z8ZpvNwM3u6gA0QtxsxtLSfI=.aec946ee-f52e-463e-af90-5d9778fd8492@github.com>
 <HVsG_LCCzlUo1f-0ZMKlCGM047qK2h9Klo3NGEPhfaM=.5717ef82-7868-43e7-bb12-9f64c434455c@github.com>
Message-ID: <dbFLtJZfh6yqYSbmciA1EVBS9tmIsO01dlNafDuNanE=.25a875db-8dc9-4152-8f40-028830bd85d3@github.com>

On Fri, 29 Apr 2022 08:29:52 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>>> Remind: please use the command `/jep JEP-424` [1] to mark this PR.
>>> 
>>> [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep
>> 
>> Question: I'm willing to try it out. If something goes wrong - would a `jep unneeded` be enough to "unstuck" this PR?
>
>> would a jep unneeded be enough to "unstuck" this PR?
> 
> Yes if no bug. Conceptually, the `/jep unneeded` will behave as no jep command.

@lgxbslgx - JEP has been targeted, but the JEP action seems to be blocking this - what should we do?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From duke at openjdk.java.net  Thu May 12 15:53:51 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 12 May 2022 15:53:51 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF [v2]
In-Reply-To: <h-1cJi4Mp30kp7L-FiEhnfqecif6Z9Vuc3qVqXfo6Q0=.2498b98c-c495-4bc8-9da2-d135b37d1fd1@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
 <h-1cJi4Mp30kp7L-FiEhnfqecif6Z9Vuc3qVqXfo6Q0=.2498b98c-c495-4bc8-9da2-d135b37d1fd1@github.com>
Message-ID: <RQCvw2Mx4_eijmUM2hTY9wZFlLMH0aziSW2T99Tvnew=.a1d64cd2-ba51-40d3-bdcd-1f6b8935dd09@github.com>

On Thu, 12 May 2022 15:48:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the specification of `SequenceInputStream.read(byte[],int,int)` to indicate that `-1` is returned at the EOF of the last stream even if `len` is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286200: Change @throws IOOBE clause of read(byte[],int,int) to better match specification verbiage

I think the same change shall apply to the `@throws NullPointerException` clause.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8664

From joehw at openjdk.java.net  Thu May 12 15:55:06 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 12 May 2022 15:55:06 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v7]
In-Reply-To: <-r3ALnm_qKjys-U2GxzdJykWJUglWqMdBglBPdmiBKs=.b8664eec-5cdc-4e6c-85f4-6c48bd393d78@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <-r3ALnm_qKjys-U2GxzdJykWJUglWqMdBglBPdmiBKs=.b8664eec-5cdc-4e6c-85f4-6c48bd393d78@github.com>
Message-ID: <_UvAX-yqqgkYdqp1UQA0V85qI5HJ-OlCMurpck7Tu2U=.902f5630-a4bb-4340-b061-7cdc63c0851e@github.com>

On Wed, 11 May 2022 05:22:22 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modify copyright year

Copyright years for XRTreeFragSelectWrapper.java and XSLTErrorResources.java were still not updated, with the later missing the LastModified tag. Please double check all files before integrate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From jvernee at openjdk.java.net  Thu May 12 15:58:04 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 15:58:04 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v15]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <RXXktMbTGQz7NdEWy87160qdd1ASRZ1YKe8zbjazy-Y=.c8f49cc5-ae8e-4a48-b477-ac23c0f455f1@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2
 - Fix overwritten copyright years.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/0f49ff0b..aab2d15c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=13-14

  Stats: 36 lines in 33 files changed: 4 ins; 0 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From sgehwolf at openjdk.java.net  Thu May 12 15:58:55 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 15:58:55 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v18]
In-Reply-To: <8rNf17Q6js-lYaRIA31S6ft-GB2fYNfpEJvNja2Blc4=.d803b76c-c43f-4569-a8aa-16fc496bdad6@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <8rNf17Q6js-lYaRIA31S6ft-GB2fYNfpEJvNja2Blc4=.d803b76c-c43f-4569-a8aa-16fc496bdad6@github.com>
Message-ID: <sq25sF5YHOrgQiTTbluMS67Krdam3wz1YGfXaaC-Ne0=.b38fa7a5-7f11-4258-ab77-7828246eeef7@github.com>

On Thu, 12 May 2022 13:46:11 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename method

LGTM.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8285

From naoto at openjdk.java.net  Thu May 12 16:01:14 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 May 2022 16:01:14 GMT
Subject: Integrated: 8286287: Reading file as UTF-16 causes Error which
 "shouldn't happen"
In-Reply-To: <oCWtLqDR1Wh8DCeIeCdLExXp9JXEPZ2LMODfe0FDaZs=.03d127d4-316d-4be0-96fc-fbfe61031dd4@github.com>
References: <oCWtLqDR1Wh8DCeIeCdLExXp9JXEPZ2LMODfe0FDaZs=.03d127d4-316d-4be0-96fc-fbfe61031dd4@github.com>
Message-ID: <UxPNwOQyR_YtVyhfOIEshvNtzJaYjjtJRHbghrc7cH0=.d545e4fa-56d1-4bf7-b2d5-bcdea588432e@github.com>

On Tue, 10 May 2022 20:22:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> `String.decodeWithDecoder()` method requires the `CharsetDecoder` parameter replaces on malformed/unmappable characters with replacements. However, there was a code path that lacked to set the `CodingErrorAction.REPLACE` on the decoder. Unrelated, one typo in a test was also fixed.

This pull request has now been integrated.

Changeset: cc7560e9
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cc7560e995eac56709d9e55a1561135fad246cb2
Stats:     54 lines in 2 files changed: 52 ins; 2 del; 0 mod

8286287: Reading file as UTF-16 causes Error which "shouldn't happen"

Reviewed-by: jpai, bpb, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8640

From jvernee at openjdk.java.net  Thu May 12 16:01:17 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 16:01:17 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v16]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <1WJgr8j7aHe_iD2t5KwVDk3c-raW7Q0NEbaSNfeo3zA=.5b14ab8c-b2a3-4fba-8209-643228a8b85d@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Undo spurious changes.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/aab2d15c..f961121a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=14-15

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From bpb at openjdk.java.net  Thu May 12 16:01:50 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 12 May 2022 16:01:50 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF [v3]
In-Reply-To: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
Message-ID: <Ek-L8Fh56fWZgWLvXKYR3qH2ol2AYjKMrWRqdQgRfjs=.3ea834cf-f3e2-4f8a-a30f-cad7320cf6d0@github.com>

> Modify the specification of `SequenceInputStream.read(byte[],int,int)` to indicate that `-1` is returned at the EOF of the last stream even if `len` is zero.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8286200: Change @throws NPE clause of read(byte[],int,int) to better match specification verbiage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8664/files
  - new: https://git.openjdk.java.net/jdk/pull/8664/files/7582dbff..111ea3e2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8664&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8664&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8664.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8664/head:pull/8664

PR: https://git.openjdk.java.net/jdk/pull/8664

From bpb at openjdk.java.net  Thu May 12 16:01:53 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 12 May 2022 16:01:53 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF [v2]
In-Reply-To: <RQCvw2Mx4_eijmUM2hTY9wZFlLMH0aziSW2T99Tvnew=.a1d64cd2-ba51-40d3-bdcd-1f6b8935dd09@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
 <h-1cJi4Mp30kp7L-FiEhnfqecif6Z9Vuc3qVqXfo6Q0=.2498b98c-c495-4bc8-9da2-d135b37d1fd1@github.com>
 <RQCvw2Mx4_eijmUM2hTY9wZFlLMH0aziSW2T99Tvnew=.a1d64cd2-ba51-40d3-bdcd-1f6b8935dd09@github.com>
Message-ID: <4uZmpqiWmFpchkc0lWKwySLaCkqNaJBFYeJHUXIr1c8=.fbe6c5b6-9f59-4850-bf55-63841db6148a@github.com>

On Thu, 12 May 2022 15:50:47 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> I think the same change shall apply to the `@throws NullPointerException` clause.

Yeah looks like it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8664

From bpb at openjdk.java.net  Thu May 12 16:01:54 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 12 May 2022 16:01:54 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF [v2]
In-Reply-To: <4uZmpqiWmFpchkc0lWKwySLaCkqNaJBFYeJHUXIr1c8=.fbe6c5b6-9f59-4850-bf55-63841db6148a@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
 <h-1cJi4Mp30kp7L-FiEhnfqecif6Z9Vuc3qVqXfo6Q0=.2498b98c-c495-4bc8-9da2-d135b37d1fd1@github.com>
 <RQCvw2Mx4_eijmUM2hTY9wZFlLMH0aziSW2T99Tvnew=.a1d64cd2-ba51-40d3-bdcd-1f6b8935dd09@github.com>
 <4uZmpqiWmFpchkc0lWKwySLaCkqNaJBFYeJHUXIr1c8=.fbe6c5b6-9f59-4850-bf55-63841db6148a@github.com>
Message-ID: <NQTuB1ziXQ5dRcoebRaG8qxElNI-ihx00BLxZvuQ6yo=.1d732862-195d-4065-a298-d8ba08f6e52f@github.com>

On Thu, 12 May 2022 15:56:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > I think the same change shall apply to the `@throws NullPointerException` clause.
> 
> Yeah looks like it.

Fixed by commit 111ea3e2f4203f05d17431953a5ffaa868176f98.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8664

From sgehwolf at openjdk.java.net  Thu May 12 16:03:01 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 16:03:01 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
In-Reply-To: <PT5BLg7JAwHZRRhw3c1HV53IHWBiuf6NFUAOMYYQTLI=.f91bbf3c-569b-49d8-85f1-62a0f8c62589@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <PT5BLg7JAwHZRRhw3c1HV53IHWBiuf6NFUAOMYYQTLI=.f91bbf3c-569b-49d8-85f1-62a0f8c62589@github.com>
Message-ID: <NR24l0clt_UoJ2At2RSbAtuOUCFnR3bFvS3rArnZTSo=.0fa3b638-7956-461c-9d2d-5441b639b3d4@github.com>

On Thu, 12 May 2022 14:00:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 113:
> 
>> 111:           }
>> 112:           buf[MAXPATHLEN-1] = '\0';
>> 113:           _path = os::strdup(buf);
> 
> I think this code can be simplified a lot with stringStream and without strtok, so no need for fixed buffers (which may fail with longer path names) and no need for writable string copies on the stack.
> 
> Something like this:
> 
> stringStream ss;
> ss.print_raw(_mount_point);
> const char* p1 = _root;
> const char* p2 = cgroup_path;
> int last_matching_dash_pos = -1;
> for (int i = 0; *p1 == *p2 && *p1 != 0; i ++) {
> 	if (*p1 == '/') {
> 		last_matching_dash_pos = i;
> 	}
>         p1++; p2++;
> }
> ss.print_raw(_root, last_matching_dash_pos);
> // Now use ss.base() to access the assembled string

Nice, thanks! I'll update it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From psandoz at openjdk.java.net  Thu May 12 16:11:58 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 12 May 2022 16:11:58 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
Message-ID: <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>

On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
>> 
>> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
>> 
>> 
>>   @ForceInline
>>   public static
>>   ByteVector fromArray(VectorSpecies<Byte> species,
>>                        byte[] a, int offset,
>>                        VectorMask<Byte> m) {
>>   ByteSpecies vsp = (ByteSpecies) species;
>>       if (offset >= 0 && offset <= (a.length - species.length())) {
>>           return vsp.dummyVector().fromArray0(a, offset, m);
>>       }
>> 
>>       // FIXME: optimize
>>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>>       return vsp.vOp(m, i -> a[offset + i]);
>>   }
>> 
>> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
>> 
>> Also adds the same vectorization support for masked:
>>  - fromByteArray/fromByteBuffer
>>  - fromBooleanArray
>>  - fromCharArray
>> 
>> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
>> 
>> Benchmark                                          before   After  Units
>> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
>> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
>> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
>> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
>> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
>> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
>> 
>> Similar performance gain can also be observed on 512-bit SVE system.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename "use_predicate" to "needs_predicate"

Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:

    719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
  ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
  ** missing constant: offsetInRange=Parm
                            @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation


So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From mbalao at openjdk.java.net  Thu May 12 16:16:49 2022
From: mbalao at openjdk.java.net (Martin Balao)
Date: Thu, 12 May 2022 16:16:49 GMT
Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <9I_lPjLJlxrQ8aeRxrpPWejELAtMQhHxXJm4UIzTozM=.1919bc6c-65b4-474f-9261-fd74d234346b@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
 <TOexKBLp4cgWmt2rLTOsW9HtmtZsNeHH7NlfHenireY=.ae3e491a-ce56-4c80-ba4b-8d31477f5498@github.com>
 <YbHOqeE8tY2qU6WpUYxRkvrJjiKQuu5qGKuDPwky7hs=.7b8ba24c-3a45-4392-b91e-ec57b8f6630c@github.com>
 <9I_lPjLJlxrQ8aeRxrpPWejELAtMQhHxXJm4UIzTozM=.1919bc6c-65b4-474f-9261-fd74d234346b@github.com>
Message-ID: <T3R4GfAqFO2vGMaI7ib-BIOA04ne3CjTzLn9Sl_0MxA=.da90ffd7-caf2-4227-b3b6-4ab5dd7e7781@github.com>

On Thu, 10 Feb 2022 15:25:09 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>>> The concerns are two folds:
>>> 
>>> * without a regression test, you have to trust that the source changes actually work, and there's typically no verification possible
>>> * without a regression test, the next refactoring change in this area two years from now could undo the fix and nobody would notice
>>> 
>> 
>> Thanks, that was what I initially thought but wanted to check if I was missing something else given the previous discussion. I should be able to generate a build for the user and ask him to test in his real environment. As for the other concern, I'll evaluate options and let you know.
>
>> Thanks, that was what I initially thought but wanted to check if I was missing something else given the previous discussion. I should be able to generate a build for the user and ask him to test in his real environment. As for the other concern, I'll evaluate options and let you know.
> 
> Thanks for the update, Martin.
> I'm ok with pushing the fix without a test given that the user will verify it in his real environment.
> Maybe, you could also log a bug for a test addition and describe in it an environment, and sort of a high-level scenario of how JDK-8275535 can be reproduced.

Hi @AlekseiEfimov ,

Apologies for the delay. We had no feedback from our customer. However, we released the fix in our builds and there were no regressions reported. I'll proceed with the integration of this fix.

Thanks,
Martin.-

-------------

PR: https://git.openjdk.java.net/jdk/pull/6043

From mbalao at openjdk.java.net  Thu May 12 16:20:48 2022
From: mbalao at openjdk.java.net (Martin Balao)
Date: Thu, 12 May 2022 16:20:48 GMT
Subject: Integrated: 8275535: Retrying a failed authentication on multiple LDAP
 servers can lead to users blocked
In-Reply-To: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
References: <ItQI5vBgeXcqWbLz9XvGALT25O26l5tLG66bGKkhees=.9abedf06-7197-44a3-b494-651ca5bb816d@github.com>
Message-ID: <us3pZt7CG9NkYjuSKQAvaenvqC-Z_zOEamjVPNZNvCQ=.f3b81dc6-f9f2-4a5b-b210-66a14b1644d6@github.com>

On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values).
> 
> No test regressions observed in jdk/com/sun/jndi/ldap.
> 
> --
> [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137

This pull request has now been integrated.

Changeset: 3be394e1
Author:    Martin Balao <mbalao at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3be394e1606dd17c2c14ce806c796f5eb2b1ad6e
Stats:     8 lines in 1 file changed: 8 ins; 0 del; 0 mod

8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked

Reviewed-by: aefimov, dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/6043

From mcimadamore at openjdk.java.net  Thu May 12 16:21:59 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 May 2022 16:21:59 GMT
Subject: Integrated: 8282191: Implementation of Foreign Function & Memory API
 (Preview)
In-Reply-To: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
Message-ID: <hmpin9Cqva6tkM3JCE4g2H_bPeBpyN3zQVylTihD-bo=.474bbfb3-127a-44de-b6e0-a5b90729f395@github.com>

On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/424

This pull request has now been integrated.

Changeset: 2c5d1362
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c5d136260fa717afa374db8b923b7c886d069b7
Stats:     65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod

8282191: Implementation of Foreign Function & Memory API (Preview)

Reviewed-by: erikj, jvernee, psandoz, dholmes, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From duke at openjdk.java.net  Thu May 12 16:26:41 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Thu, 12 May 2022 16:26:41 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v16]
In-Reply-To: <1WJgr8j7aHe_iD2t5KwVDk3c-raW7Q0NEbaSNfeo3zA=.5b14ab8c-b2a3-4fba-8209-643228a8b85d@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <1WJgr8j7aHe_iD2t5KwVDk3c-raW7Q0NEbaSNfeo3zA=.5b14ab8c-b2a3-4fba-8209-643228a8b85d@github.com>
Message-ID: <DRtaGN6gZMfMiQkoAocJtXs_e50HPerU7HNa6Xex_Ek=.36ed2221-9860-4147-92c1-333238d58a63@github.com>

On Thu, 12 May 2022 16:01:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
>> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
>> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
>> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Undo spurious changes.

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout JEP-19-VM-IMPL2
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From darcy at openjdk.java.net  Thu May 12 16:50:32 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 12 May 2022 16:50:32 GMT
Subject: RFR: JDK-8286615: Small refactor to SerializedLambda [v2]
In-Reply-To: <wpYuGehq7x3d8YRH0ja0_JRfNZy1ihXW3yldLUx5ZQc=.af897cbf-e942-4631-a6e9-37c73351a3cb@github.com>
References: <wpYuGehq7x3d8YRH0ja0_JRfNZy1ihXW3yldLUx5ZQc=.af897cbf-e942-4631-a6e9-37c73351a3cb@github.com>
Message-ID: <jcpF0nVJDFDMBp8eZUoRCI6QJ_MxwDuqu0yJNUzuNBk=.0d3d7554-c03a-41ff-aa07-6325c377acbf@github.com>

> Noticed by inspection during a CSR review, small refactoring to use a message-cause exception constructor when one is available.
> 
> Will update the copyright before a push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8670/files
  - new: https://git.openjdk.java.net/jdk/pull/8670/files/82d7ab2c..6b15c809

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8670&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8670&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8670.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8670/head:pull/8670

PR: https://git.openjdk.java.net/jdk/pull/8670

From rriggs at openjdk.java.net  Thu May 12 16:54:48 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 May 2022 16:54:48 GMT
Subject: Integrated: 8286378: Address possibly lossy conversions in java.base
In-Reply-To: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
Message-ID: <WHMEywerPxetkdgvJXfdFg-DBiIp-Asn2kKRAhorZoY=.f73e75a5-7eb8-4bb1-9d8a-486164f40f92@github.com>

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

This pull request has now been integrated.

Changeset: 17c52789
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/17c52789b79a4ccd65308f90c4e02c1732b206be
Stats:     71 lines in 32 files changed: 0 ins; 3 del; 68 mod

8286378: Address possibly lossy conversions in java.base

Reviewed-by: naoto, xuelei, bpb, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From duke at openjdk.java.net  Thu May 12 16:55:56 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 12 May 2022 16:55:56 GMT
Subject: RFR: JDK-8286347: incorrect use of `{@link}`
In-Reply-To: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
References: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
Message-ID: <ZfIs4eUmpztFSuUVea0rF78T3WIH_dGnwVctCdJbphM=.8f7095bf-948c-4b76-ba47-2fcc5070b0d1@github.com>

On Fri, 6 May 2022 23:30:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small doc fix to update incorrect use of `{@link}` on arrays of primitive types.

This is fixed in 8282191 (JEP 424), which is already integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8584

From rriggs at openjdk.java.net  Thu May 12 16:57:18 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 May 2022 16:57:18 GMT
Subject: RFR: 8286393: Address possibly lossy conversions in java.rmi
Message-ID: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>

Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599.

Explicit casts are inserted where implicit casts occur.

8286393: Address possibly lossy conversions in java.rmi
8286388: Address possibly lossy conversions in java.smartcardio

-------------

Commit messages:
 - 8286393: Address possibly lossy conversions in java.rmi

Changes: https://git.openjdk.java.net/jdk/pull/8683/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8683&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286393
  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8683/head:pull/8683

PR: https://git.openjdk.java.net/jdk/pull/8683

From jvernee at openjdk.java.net  Thu May 12 16:58:36 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 16:58:36 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v17]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <v-RW6Kh99Q2WigOra-aW599y5SrU145TK7TMD2qSSCA=.18c31c72-4e2d-435d-93a0-f0fa0f515287@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits:

 - Merge branch 'master' into JEP-19-VM-IMPL2
 - Undo spurious changes.
 - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2
 - Apply copyright year updates per request of @nick-arm
   
   Co-authored-by: Nick Gasson <nick.gasson at arm.com>
 - Fix overwritten copyright years.
 - Missed 2 years
 - Update Oracle copyright years
 - Revert "Block async exceptions during upcalls"
   
   This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790.
 - Block async exceptions during upcalls
 - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
 - ... and 88 more: https://git.openjdk.java.net/jdk/compare/2c5d1362...f55b6c59

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7959/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=16
  Stats: 6913 lines in 155 files changed: 2576 ins; 3219 del; 1118 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From darcy at openjdk.java.net  Thu May 12 17:00:06 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 12 May 2022 17:00:06 GMT
Subject: Integrated: JDK-8286615: Small refactor to SerializedLambda
In-Reply-To: <wpYuGehq7x3d8YRH0ja0_JRfNZy1ihXW3yldLUx5ZQc=.af897cbf-e942-4631-a6e9-37c73351a3cb@github.com>
References: <wpYuGehq7x3d8YRH0ja0_JRfNZy1ihXW3yldLUx5ZQc=.af897cbf-e942-4631-a6e9-37c73351a3cb@github.com>
Message-ID: <IwMdkKPSq4blN4ERIbTC94hJZncSBMUT6IbrmE9_x0c=.40c20bbc-b08b-48cf-8b80-a90b5c9881a3@github.com>

On Thu, 12 May 2022 00:10:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Noticed by inspection during a CSR review, small refactoring to use a message-cause exception constructor when one is available.
> 
> Will update the copyright before a push.

This pull request has now been integrated.

Changeset: 160944bc
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/160944bc6bd94d2927f398cf7732027c1b836a42
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8286615: Small refactor to SerializedLambda

Reviewed-by: bpb, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/8670

From duke at openjdk.java.net  Thu May 12 17:01:50 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 12 May 2022 17:01:50 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF [v3]
In-Reply-To: <Ek-L8Fh56fWZgWLvXKYR3qH2ol2AYjKMrWRqdQgRfjs=.3ea834cf-f3e2-4f8a-a30f-cad7320cf6d0@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
 <Ek-L8Fh56fWZgWLvXKYR3qH2ol2AYjKMrWRqdQgRfjs=.3ea834cf-f3e2-4f8a-a30f-cad7320cf6d0@github.com>
Message-ID: <3SBzYmHiq1BFynjOyCqPUm75wnkOAGkbjn_dCsata3s=.baa9903c-aba4-4ab7-88b6-8f5b5649a8ff@github.com>

On Thu, 12 May 2022 16:01:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the specification of `SequenceInputStream.read(byte[],int,int)` to indicate that `-1` is returned at the EOF of the last stream even if `len` is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286200: Change @throws NPE clause of read(byte[],int,int) to better match specification verbiage

_(not a reviewer)_
Looks good

-------------

Marked as reviewed by rgiulietti at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/8664

From iklam at openjdk.java.net  Thu May 12 17:16:34 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 12 May 2022 17:16:34 GMT
Subject: RFR: 8286560: Remove user parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>
References: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>
Message-ID: <WihdyuxN1woj4IvUdlrke79gXowdqI447CJV4wQ2aOM=.a4affe8f-e60f-4479-8e0a-8fa224152e78@github.com>

> The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @AlanBateman comments - remove thros IllegalArgumentException clause

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8669/files
  - new: https://git.openjdk.java.net/jdk/pull/8669/files/afa66232..0b73a9d4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8669&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8669&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8669.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8669/head:pull/8669

PR: https://git.openjdk.java.net/jdk/pull/8669

From jvernee at openjdk.java.net  Thu May 12 17:30:00 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 17:30:00 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <i3sR3qKBIRAlzLMcpbq7kgWfv7b2T9O-KCPXlEljb-0=.fe5edce0-91fb-4549-a8e1-f36cfa549ddc@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
 <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
 <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>
 <T73dHwsxmGWzDhJzzaLzEkOpsi6LB7jHBwcBI-JTJlY=.3929d080-0ae2-4645-88db-f5dfa8f0e855@github.com>
 <AIN9VRXcDj-YKtSkychFW7_ZqXdx3AsWmeMnvzJchl8=.680b9133-929d-4a47-809a-2a654a94bf26@github.com>
 <WCNDNQabM_3gZBaog255y0LSokj044con0d23ZeQ7hA=.cfae3ed7-b420-47fc-bf73-f7f65cddf385@github.com>
 <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com>
 <vO8ppClc_A5MhswLQXuTi-T2_3RAoTg6X69
 O1sbQVI8=.15e3f5c1-7bed-4d73-a703-e3737b9f3a4a@github.com>
 <i3sR3qKBIRAlzLMcpbq7kgWfv7b2T9O-KCPXlEljb-0=.fe5edce0-91fb-4549-a8e1-f36cfa549ddc@github.com>
Message-ID: <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com>

On Thu, 12 May 2022 12:10:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Okay, I see. I think I acted a little too hastily on this yesterday.  I'll revert the change that uses this blocking mechanism.
>> 
>> The stack more or less looks like this during an upcall:
>> 
>> 
>> | ---
>> | <younger frames> |
>> | ---
>> | <1: user define try block with exception handler (maybe)> |
>> | ---
>> | <2: user code start> |
>> | ---
>> | <3: method handle impl frames 1> |
>> | ---
>> | <4: upcall wrapper class with fallback handler 1> |
>> | ---
>> | <5: method handle impl frames 2> |
>> | ---
>> | <6: upcallk stub with fallback handler 2> |
>> | <7: unknown native code>
>> | ---
>> | <older frames> |
>> 
>> 
>> I think there are several options to address async exceptions:
>> 1. Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated.
>> 2. Block async exceptions in all code up from 6.
>> 3. Somehow only block async exceptions only between 6. and 1. 
>>     I think that is possible by changing the API so that the user passes us a method handle to their fallback exception handler, and we invoke it in our code in 4. We would need 2 methods for blocking and unblocking async exceptions from Java. Then we could disable async exceptions at the start of 6. enabled them at the start of the try block in 4. (around the call to user code), and disable them at the end of this try block. Then finally re-enable them at the end of 6. If an exception occurs in the try block in 4., delegate to the user-defined exception handler (but use the VM terminate strategy as a fallback for when another exception occurs). The other problem I see with that is that to make that fast enough (i.e. not incur a ~1.5-2x cost on call overhead), we would need compiler intrinsics for the blocking/unblocking, and in the past we've been unable to define 'critical' sections of code like that in C2 (it's an unsolved problem at this point).
>
>> Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated.
> 
> My understanding is that if they materialize while we're executing the upcall Java code, if that code has a try/catch block, we will go there, rather than crash the VM.
> 
> In other words, IMHO the only problem with async exception is if they occur _after_ the Java user code has completed, because that will crash the Java adapter, this preventing it from returning to native call cleanly.
> 
> So, either we disable async exceptions during that phase (e.g. after user code has executed, but before we return back to native code), or we just punt and stop. Since this seems like a corner^3 case, and since there are also other issue with upcalls that can occur if other threads do not cooperate (e.g. an upcall can get stuck into an infinite safepoint if the VM exits while an async native thread runs the upcall), and given that obtaining a linker is a restricted operation anyway, I don't think we should bend over backwards to try to add 1% more safety to something that's unavoidably sharp anyways.

Ok. Then, if no one objects, I will leave this area as-is for now. (and perhaps come back to this issue in the future, if it becomes more pressing).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From asemenyuk at openjdk.java.net  Thu May 12 17:34:44 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 12 May 2022 17:34:44 GMT
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe [v2]
In-Reply-To: <BtITAMIGuPEYwTYNhIHiSepf6tS1nr5Eu_BHGz1Zw14=.4c77c962-801f-419f-82e8-39971325961a@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <BtITAMIGuPEYwTYNhIHiSepf6tS1nr5Eu_BHGz1Zw14=.4c77c962-801f-419f-82e8-39971325961a@github.com>
Message-ID: <6w_XCI-RPohWecEn7OmAIgEJ-fDz1s3fAoVerdZr_js=.374070ee-c1c6-4455-81a2-09a07441ad87@github.com>

On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.
>>  - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles.
>>  - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error.
>>  - Added two tests to validate fix.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8666

From jvernee at openjdk.java.net  Thu May 12 17:36:31 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 17:36:31 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline
Message-ID: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>

Hi,

This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.

Thanks,
Jorn

-------------

Depends on: https://git.openjdk.java.net/jdk/pull/7959

Commit messages:
 - Fix LinkUpcall benchmark
 - 8286306: Upcall wrapper class sharing
 - Polish
 - 8281595: ASM-ify scope acquire/release for down call parameters
 - 8281228: Preview branch's CLinker.downcallHandle crashes inside asm
 - 8278414: Replace binding recipe customization using MH combinators with bytecode spinning
 - 8276648: Downcall stubs are never freed

Changes: https://git.openjdk.java.net/jdk/pull/8685/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286669
  Stats: 2171 lines in 24 files changed: 1384 ins; 660 del; 127 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8685.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8685/head:pull/8685

PR: https://git.openjdk.java.net/jdk/pull/8685

From lancea at openjdk.java.net  Thu May 12 17:36:57 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 12 May 2022 17:36:57 GMT
Subject: RFR: 8286393: Address possibly lossy conversions in java.rmi
In-Reply-To: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>
References: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>
Message-ID: <gR-HoE3H8ynJYZp6vSX12Emc6Ct9KqbV9NEKINS12AA=.6bfa8ad5-bc08-4402-afbd-a337ed9d2fb2@github.com>

On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599.
> 
> Explicit casts are inserted where implicit casts occur.
> 
> 8286393: Address possibly lossy conversions in java.rmi
> 8286388: Address possibly lossy conversions in java.smartcardio

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8683

From dfuchs at openjdk.java.net  Thu May 12 17:43:49 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 12 May 2022 17:43:49 GMT
Subject: RFR: 8286393: Address possibly lossy conversions in java.rmi
In-Reply-To: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>
References: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>
Message-ID: <vnoV4rVHm7qq5U368bRDTcc8KAoEllj89wsNfdF2UOE=.1be3e4b7-c7e4-4ebd-80f9-61d838e69e7e@github.com>

On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599.
> 
> Explicit casts are inserted where implicit casts occur.
> 
> 8286393: Address possibly lossy conversions in java.rmi
> 8286388: Address possibly lossy conversions in java.smartcardio

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8683

From duke at openjdk.java.net  Thu May 12 18:02:26 2022
From: duke at openjdk.java.net (Shruthi)
Date: Thu, 12 May 2022 18:02:26 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

Shruthi 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:

  Modify copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8318/files
  - new: https://git.openjdk.java.net/jdk/pull/8318/files/283f8ef9..bcad12ea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8318&range=06-07

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8318/head:pull/8318

PR: https://git.openjdk.java.net/jdk/pull/8318

From sgehwolf at openjdk.java.net  Thu May 12 18:09:40 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 18:09:40 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
Message-ID: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>

> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
> 
> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
> 
> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
> 
> Testing:
> - [x] Added unit tests
> - [x] GHA
> - [x] Container tests on cgroups v1 Linux. Continue to pass

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Use stringStream to simplify controller path assembly

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8629/files
  - new: https://git.openjdk.java.net/jdk/pull/8629/files/bc873b3f..66241aa5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=00-01

  Stats: 32 lines in 1 file changed: 0 ins; 21 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8629.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8629/head:pull/8629

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Thu May 12 18:09:41 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 12 May 2022 18:09:41 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <NR24l0clt_UoJ2At2RSbAtuOUCFnR3bFvS3rArnZTSo=.0fa3b638-7956-461c-9d2d-5441b639b3d4@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <PT5BLg7JAwHZRRhw3c1HV53IHWBiuf6NFUAOMYYQTLI=.f91bbf3c-569b-49d8-85f1-62a0f8c62589@github.com>
 <NR24l0clt_UoJ2At2RSbAtuOUCFnR3bFvS3rArnZTSo=.0fa3b638-7956-461c-9d2d-5441b639b3d4@github.com>
Message-ID: <LEj5namOIjF-CUA3NPXu_N2eX_-uIhQoKS8nOLfswO0=.fd38089b-bab5-43c2-af80-47dfdbaebc0d@github.com>

On Thu, 12 May 2022 15:58:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 113:
>> 
>>> 111:           }
>>> 112:           buf[MAXPATHLEN-1] = '\0';
>>> 113:           _path = os::strdup(buf);
>> 
>> I think this code can be simplified a lot with stringStream and without strtok, so no need for fixed buffers (which may fail with longer path names) and no need for writable string copies on the stack.
>> 
>> Something like this:
>> 
>> stringStream ss;
>> ss.print_raw(_mount_point);
>> const char* p1 = _root;
>> const char* p2 = cgroup_path;
>> int last_matching_dash_pos = -1;
>> for (int i = 0; *p1 == *p2 && *p1 != 0; i ++) {
>> 	if (*p1 == '/') {
>> 		last_matching_dash_pos = i;
>> 	}
>>         p1++; p2++;
>> }
>> ss.print_raw(_root, last_matching_dash_pos);
>> // Now use ss.base() to access the assembled string
>
> Nice, thanks! I'll update it.

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From duke at openjdk.java.net  Thu May 12 18:20:00 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 12 May 2022 18:20:00 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline
In-Reply-To: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
Message-ID: <_vOeEJsQJfMPt3ECcI2OKwrFBS4WPRqJA8O6YtFkiI4=.f5285c7b-cf85-4f6e-a206-1262ee29bec2@github.com>

On Thu, 12 May 2022 17:17:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
> 
> Thanks,
> Jorn

test/micro/org/openjdk/bench/java/lang/foreign/LinkUpcall.java line 61:

> 59:             BLANK = lookup().findStatic(LinkUpcall.class, "blank", MethodType.methodType(void.class));
> 60:         } catch (ReflectiveOperationException e) {
> 61:             throw new BootstrapMethodError(e);

You probably mean exception in initializer error.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From iklam at openjdk.java.net  Thu May 12 18:20:57 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 12 May 2022 18:20:57 GMT
Subject: RFR: 8286560: Remove user parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <JQ_ylMKNoRy1kkoWipgbfViPWTJf1BI74vWQwMaCF1o=.abb9c0d8-68b6-4abc-af88-8e5dd3ce3312@github.com>
References: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>
 <JQ_ylMKNoRy1kkoWipgbfViPWTJf1BI74vWQwMaCF1o=.abb9c0d8-68b6-4abc-af88-8e5dd3ce3312@github.com>
Message-ID: <io27hHQhI7YzLxQx8gXLceaWSAzA4GQavLq-j4T4IZs=.d3805f7a-6fc5-4361-bfff-d901e6f63f46@github.com>

On Thu, 12 May 2022 04:06:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @AlanBateman comments - remove thros IllegalArgumentException clause
>
> Nice cleanup! I checked back in JDK 7 and couldn't find any use of this particular API.
> 
> Thanks.

Thanks to @dholmes-ora and @AlanBateman for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8669

From iklam at openjdk.java.net  Thu May 12 18:21:00 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 12 May 2022 18:21:00 GMT
Subject: RFR: 8286560: Remove user parameter from
 jdk.internal.perf.Perf.attach() [v2]
In-Reply-To: <NPEyR1B0lyWvAe7_IpvfX_YvcjEORCNjVB5XWApAfUQ=.3242177b-9598-4b46-96cd-1be23c351e39@github.com>
References: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>
 <NPEyR1B0lyWvAe7_IpvfX_YvcjEORCNjVB5XWApAfUQ=.3242177b-9598-4b46-96cd-1be23c351e39@github.com>
Message-ID: <RuiFpR31uybGj1_hlbpc1u3y-pTCgWspWYSs1EKzJqg=.00b24faf-2018-4abe-ae0c-e971dd15249f@github.com>

On Thu, 12 May 2022 14:08:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @AlanBateman comments - remove thros IllegalArgumentException clause
>
> src/java.base/share/classes/jdk/internal/perf/Perf.java line 246:
> 
>> 244:      */
>> 245:     private native ByteBuffer attach0(int lvmid)
>> 246:                    throws IllegalArgumentException, IOException;
> 
> You can drop the "throws IllegalArgumentException" here if you want, it's not needed as it's a runtime exception.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8669

From iklam at openjdk.java.net  Thu May 12 18:21:03 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 12 May 2022 18:21:03 GMT
Subject: Integrated: 8286560: Remove user parameter from
 jdk.internal.perf.Perf.attach()
In-Reply-To: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>
References: <IXm97v5WToC0GM1Acntg7RjPeAVdpYbLQVVhYCzrMZ0=.c26f97a9-20ac-455b-8c02-3b97757e4cc9@github.com>
Message-ID: <384C9guIuWTysRpqKNFMYODCCbfDkRMGVuxpFGm4DrQ=.aa54d9fc-00d1-4589-a0aa-1f3f1eee7b42@github.com>

On Wed, 11 May 2022 23:08:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed.

This pull request has now been integrated.

Changeset: 74eee28a
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/74eee28a710f2d0c9f613522ee3d228d6b601252
Stats:     123 lines in 5 files changed: 2 ins; 97 del; 24 mod

8286560: Remove user parameter from jdk.internal.perf.Perf.attach()

Reviewed-by: dholmes, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8669

From kbarrett at openjdk.java.net  Thu May 12 18:31:49 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 12 May 2022 18:31:49 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4]
In-Reply-To: <cbS0XWcBC0vi8SjU3V3dS4feDWBnMbPjSyCXqoPGcb4=.f2cdf49d-0915-46b1-b436-e3699e94892c@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <hRz0_TToYgAPiC2722w2E0YzZztTp34v74R4OM6A78k=.f5ae0319-cd63-421a-b416-652757587567@github.com>
 <cbS0XWcBC0vi8SjU3V3dS4feDWBnMbPjSyCXqoPGcb4=.f2cdf49d-0915-46b1-b436-e3699e94892c@github.com>
Message-ID: <FhmdALeuSc3nk12GIb6HDLsugYmiWDHzlzn_5Zmuoq8=.46d91385-b9e6-49f6-bd41-6e00f46b8115@github.com>

On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Calculate char offset before realloc()
>
> Thanks for all to review this PR! I think we should separate this issue as following:
> 
> * Suppress warnings
>     * make/modules/java.desktop/lib/Awt2dLibraries.gmk
>     * src/hotspot/share/classfile/bytecodeAssembler.cpp
>     * src/hotspot/share/classfile/classFileParser.cpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>     * src/hotspot/share/opto/memnode.cpp
>     * src/hotspot/share/opto/type.cpp
>     * src/hotspot/share/utilities/compilerWarnings.hpp
>     * src/hotspot/share/utilities/compilerWarnings_gcc.hpp
>     * src/java.base/unix/native/libjli/java_md_common.c
> * Bug fixes
>     * src/java.base/share/native/libjli/java.c
>     * src/java.base/share/native/libjli/parse_manifest.c
>     * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c
> 
> I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library.
> 
> I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only.

> @YaSuenag From my PoV this sounds like a good suggestion.

+1

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From rriggs at openjdk.java.net  Thu May 12 19:03:58 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 May 2022 19:03:58 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF [v3]
In-Reply-To: <Ek-L8Fh56fWZgWLvXKYR3qH2ol2AYjKMrWRqdQgRfjs=.3ea834cf-f3e2-4f8a-a30f-cad7320cf6d0@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
 <Ek-L8Fh56fWZgWLvXKYR3qH2ol2AYjKMrWRqdQgRfjs=.3ea834cf-f3e2-4f8a-a30f-cad7320cf6d0@github.com>
Message-ID: <zpTKzARA3v4-gSW3sSrfHfqRgdkC7yrh8MqtnFKjAVI=.3ce36d05-dc0b-4f6b-8e31-6de513be9fa2@github.com>

On Thu, 12 May 2022 16:01:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the specification of `SequenceInputStream.read(byte[],int,int)` to indicate that `-1` is returned at the EOF of the last stream even if `len` is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286200: Change @throws NPE clause of read(byte[],int,int) to better match specification verbiage

In the throws clauses, I think I would have put the additional conditional at the end of the sentence since the existing throws text corresponds to the exception.
But the logic is correct as is.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8664

From joehw at openjdk.java.net  Thu May 12 19:05:03 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 12 May 2022 19:05:03 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
Message-ID: <4Dt8fXPreMboUhRhApWQ11A5iNtvWcdsJQTjGCH2AlE=.3ca8b874-0293-4c3c-9794-9648307072b1@github.com>

On Thu, 12 May 2022 18:02:26 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi 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:
> 
>   Modify copyright year

They all look good now. Thanks.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8318

From prr at openjdk.java.net  Thu May 12 19:10:51 2022
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 12 May 2022 19:10:51 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4]
In-Reply-To: <hRz0_TToYgAPiC2722w2E0YzZztTp34v74R4OM6A78k=.f5ae0319-cd63-421a-b416-652757587567@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <hRz0_TToYgAPiC2722w2E0YzZztTp34v74R4OM6A78k=.f5ae0319-cd63-421a-b416-652757587567@github.com>
Message-ID: <D95XNso2D3HCyzEdDK2UqdOYZIFMPz6JTXLpK5SnZUA=.b531eed5-6423-49cc-9d08-d59f7b56ae46@github.com>

On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Calculate char offset before realloc()

I will see what upstream thinks about the harfbuzz warning but in the mean time we can just disable it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From darcy at openjdk.java.net  Thu May 12 19:54:35 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 12 May 2022 19:54:35 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec
In-Reply-To: <2ianG0Dk2e14SluE2qzVa3tos1_Wcj2CyT8ZBwtMMX8=.9bb5a89b-b577-43a5-8ff9-5d2c280156a8@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
 <2ianG0Dk2e14SluE2qzVa3tos1_Wcj2CyT8ZBwtMMX8=.9bb5a89b-b577-43a5-8ff9-5d2c280156a8@github.com>
Message-ID: <kfcdbAWxMxQmHG5gQ-NBx3LjmcTqgeA9Zu1X3g-ZvXU=.302d0384-8032-4be8-91f1-c0bb46065b70@github.com>

On Thu, 12 May 2022 12:24:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.
>> 
>> The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.
>> 
>> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605
>
> src/java.base/share/classes/java/io/InputStream.java line 177:
> 
>> 175:      *
>> 176:      * @apiNote
>> 177:      * A subclass must provide an implementation of this method.
> 
> Is this sentence useful to keep? The method is abstract so a concrete implementation has to implement it. On the other other hand, an abstract subclass does not need to implement it.

If such a sentence occurred in new code, I would recommend it be removed. I left it in place in the spirit of just adding apiNote, implSpec, etc., but I'm happy to delete these comments too. I assume it was deemed useful to readers of JDK 1.0, but the assumed background of Java developers now is rather different :-)

> src/java.base/share/classes/java/io/InputStream.java line 688:
> 
>> 686:      * @implSpec
>> 687:      * The {@code mark} method of {@code InputStream} does
>> 688:      * nothing.
> 
> Minor nit but the line break can be removed so that "nothing" is on the same line.

Sure. (I default to not making such reflow changes in the initial version of a patch to avoid spurious diffs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8663

From darcy at openjdk.java.net  Thu May 12 20:04:33 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 12 May 2022 20:04:33 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec [v2]
In-Reply-To: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
Message-ID: <-Y_Pqp9Jl0JMpvC3z7-RASDhRSvhOamEZWPh_FUhpkU=.27334dd1-c0cd-46ca-b18f-10bc80444993@github.com>

> While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.
> 
> The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8663/files
  - new: https://git.openjdk.java.net/jdk/pull/8663/files/a29e5c36..7d88f44c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8663&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8663&range=00-01

  Stats: 13 lines in 2 files changed: 3 ins; 8 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8663/head:pull/8663

PR: https://git.openjdk.java.net/jdk/pull/8663

From darcy at openjdk.java.net  Thu May 12 20:04:34 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 12 May 2022 20:04:34 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec [v2]
In-Reply-To: <q1cnGl_ulTmktyFm3kDjgtzHb9wI1pgWovogZsaF6co=.8f872b3a-d0d6-47de-a3ed-633f53a461e4@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
 <q1cnGl_ulTmktyFm3kDjgtzHb9wI1pgWovogZsaF6co=.8f872b3a-d0d6-47de-a3ed-633f53a461e4@github.com>
Message-ID: <-hf7-VjFsZxgXPiK63HTjb6pxwKHvarRwqsbu-MosJQ=.db63add8-2f6f-4d74-ad5e-efc982a5d3bd@github.com>

On Wed, 11 May 2022 22:43:43 GMT, liach <duke at openjdk.java.net> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/java/io/OutputStream.java line 151:
> 
>> 149:      * The {@code write} method of {@code OutputStream} calls
>> 150:      * the write method of one argument on each of the bytes to be
>> 151:      * written out. Subclasses are encouraged to override this method and
> 
> Shouldn't the "subclasses" information be part of the API Note?

Sure; moved to an apiNote.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8663

From darcy at openjdk.java.net  Thu May 12 20:08:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 12 May 2022 20:08:42 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec [v2]
In-Reply-To: <-Y_Pqp9Jl0JMpvC3z7-RASDhRSvhOamEZWPh_FUhpkU=.27334dd1-c0cd-46ca-b18f-10bc80444993@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
 <-Y_Pqp9Jl0JMpvC3z7-RASDhRSvhOamEZWPh_FUhpkU=.27334dd1-c0cd-46ca-b18f-10bc80444993@github.com>
Message-ID: <t1j0_7hw_MvWo11AdScnXVbL_QM6sYD1miV0eRELHXs=.2c5fbf43-df18-4f8c-a4dd-001275f69595@github.com>

On Thu, 12 May 2022 20:04:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.
>> 
>> The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.
>> 
>> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

CSR also updated to reflect changes made in response to review comments; thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8663

From ihse at openjdk.java.net  Thu May 12 20:13:48 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 12 May 2022 20:13:48 GMT
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe [v2]
In-Reply-To: <BtITAMIGuPEYwTYNhIHiSepf6tS1nr5Eu_BHGz1Zw14=.4c77c962-801f-419f-82e8-39971325961a@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <BtITAMIGuPEYwTYNhIHiSepf6tS1nr5Eu_BHGz1Zw14=.4c77c962-801f-419f-82e8-39971325961a@github.com>
Message-ID: <myD1zyy5nKewZGH-L4i3Yt7bzd0xpSwHdx1OWPiMzbo=.14ed97bb-de73-408d-9707-1ec728c22c4d@github.com>

On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.
>>  - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles.
>>  - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error.
>>  - Added two tests to validate fix.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]

We have the `NSMicrophoneUsageDescription` permission on the `java` launcher in the JDK, since otherwise no Java program can access the mike, even though most won't care. I agree that the situation is different for a jpackaged app, where the developer knows if that permission is needed or not.

Yes, plistbuddy is an official Apple program.

My understanding of the PR was that native commands are removed by jlink if the user is packaging on a mac for the App Store. I thought this was a workaround that solved the immediate problem of not being able to submit the app to App Store. (However, I don't know how the app is supposed to be started without a launcher...)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8666

From mik3hall at gmail.com  Thu May 12 20:58:18 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 12 May 2022 15:58:18 -0500
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe [v2]
In-Reply-To: <myD1zyy5nKewZGH-L4i3Yt7bzd0xpSwHdx1OWPiMzbo=.14ed97bb-de73-408d-9707-1ec728c22c4d@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <BtITAMIGuPEYwTYNhIHiSepf6tS1nr5Eu_BHGz1Zw14=.4c77c962-801f-419f-82e8-39971325961a@github.com>
 <myD1zyy5nKewZGH-L4i3Yt7bzd0xpSwHdx1OWPiMzbo=.14ed97bb-de73-408d-9707-1ec728c22c4d@github.com>
Message-ID: <A45BBAAD-DC39-4DC9-A7B5-37320D92E9BC@gmail.com>



> On May 12, 2022, at 3:13 PM, Magnus Ihse Bursie <ihse at openjdk.java.net> wrote:
> 
> On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:
> 
>>> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.
>>> - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles.
>>> - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error.
>>> - Added two tests to validate fix.
>> 
>> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]
> 
> We have the `NSMicrophoneUsageDescription` permission on the `java` launcher in the JDK, since otherwise no Java program can access the mike, even though most won't care. I agree that the situation is different for a jpackaged app, where the developer knows if that permission is needed or not.

I?d have to agree with Apple DTS that this is an interesting exception. 

> 
> Yes, plistbuddy is an official Apple program.
> 
> My understanding of the PR was that native commands are removed by jlink if the user is packaging on a mac for the App Store. I thought this was a workaround that solved the immediate problem of not being able to submit the app to App Store. (However, I don't know how the app is supposed to be started without a launcher?)
> 

I thought that if the app was indicated as intended for the App Store and native commands were also indicated an error would be thrown and the app not built. It doesn?t allow apps that will fail to attempt the App Store but does nothing for getting them there. Switching from an error to a warning and forcing the native commands to be stripped would allow the app into the app store but with unknown functionality probably not working. My understanding. 


From jvernee at openjdk.java.net  Thu May 12 21:25:52 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 May 2022 21:25:52 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline
In-Reply-To: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
Message-ID: <VPdj3VyDHN5OwdAGRiQJp7LgEQf2AI5r14YSBVLzmoc=.4e4d8803-d61b-430d-b4f3-53533bee92e3@github.com>

On Thu, 12 May 2022 17:17:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
> 
> Thanks,
> Jorn

Hmm, looks like there's an unexpected a tier1 failure on SysV in the GHA (I only tested Windows locally, since these changes have been live in the panama repo for a while now...). Will convert back to draft and see what's up.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From clanger at openjdk.java.net  Thu May 12 22:08:50 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Thu, 12 May 2022 22:08:50 GMT
Subject: RFR: 8286594: (zipfs) Mention paths with dot elements in
 ZipException and cleanups
In-Reply-To: <_uQj3PWsPqeX42kZya_w-wVyE0Ir8LGVY1fVJdOx97o=.491ece42-760d-4644-82ba-54f220a518b8@github.com>
References: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com>
 <_uQj3PWsPqeX42kZya_w-wVyE0Ir8LGVY1fVJdOx97o=.491ece42-760d-4644-82ba-54f220a518b8@github.com>
Message-ID: <7C-ClU-gLSbuuqyONkNC-Vrko3TQFb5nvAYxFXndzfM=.0ffd1c59-d271-4346-a1be-6b9212730e7c@github.com>

On Thu, 12 May 2022 15:07:29 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> A more descriptive title for the bug report would be helpful.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8655

From forax at univ-mlv.fr  Thu May 12 22:11:47 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 13 May 2022 00:11:47 +0200 (CEST)
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline
In-Reply-To: <VPdj3VyDHN5OwdAGRiQJp7LgEQf2AI5r14YSBVLzmoc=.4e4d8803-d61b-430d-b4f3-53533bee92e3@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <VPdj3VyDHN5OwdAGRiQJp7LgEQf2AI5r14YSBVLzmoc=.4e4d8803-d61b-430d-b4f3-53533bee92e3@github.com>
Message-ID: <1527742474.1903577.1652393507927.JavaMail.zimbra@u-pem.fr>

Ok,
let us know when it's out of draft,
i've several minor modifications about the code.

regards,
R?mi

----- Original Message -----
> From: "Jorn Vernee" <jvernee at openjdk.java.net>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev" <hotspot-dev at openjdk.java.net>
> Sent: Thursday, May 12, 2022 11:25:52 PM
> Subject: Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline

> On Thu, 12 May 2022 17:17:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:
> 
>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly
>> pertain to the switch to ASM and away from MethodHandle combinators for the
>> binding recipe specialization. But, there is one more commit which adds freeing
>> of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
> 
> Hmm, looks like there's an unexpected a tier1 failure on SysV in the GHA (I only
> tested Windows locally, since these changes have been live in the panama repo
> for a while now...). Will convert back to draft and see what's up.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/8685

From asemenyuk at openjdk.java.net  Thu May 12 23:39:44 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 12 May 2022 23:39:44 GMT
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <A45BBAAD-DC39-4DC9-A7B5-37320D92E9BC@gmail.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <A45BBAAD-DC39-4DC9-A7B5-37320D92E9BC@gmail.com>
Message-ID: <8KF1pLYghl_meLa6EP_pfVbtb7h-V2oMs9QtOBdMHd0=.396e291a-5139-4bc6-9e7a-44146e714dd8@github.com>

On Thu, 12 May 2022 20:59:53 GMT, Michael Hall <mik3hall at gmail.com> wrote:

> However, I don't know how the app is supposed to be started without a launcher...

jpackage supplies an alternative launcher that doesn't have plist.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8666

From vlivanov at openjdk.java.net  Thu May 12 23:59:46 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 12 May 2022 23:59:46 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v3]
In-Reply-To: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
Message-ID: <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>

On Tue, 10 May 2022 12:48:25 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Correcting a typo.
>  - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: AARCH64 backend changes.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...b021e082

Overall, looks good.

Some minor questions/suggestions follow.

src/hotspot/cpu/aarch64/aarch64_neon.ad line 5700:

> 5698:                 as_FloatRegister($dst$$reg));
> 5699:     }
> 5700:     if (bt == T_INT) {

I find it hard to reason about the code in its current form.

Maybe make the second `if` (`bt == T_INT`) nested and move it under  `if (bt == T_SHORT || bt == T_INT)`?

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 2587:

> 2585: 
> 2586: void MacroAssembler::vmovdqu(XMMRegister dst, AddressLiteral src, Register scratch_reg, int vector_len) {
> 2587:   assert(vector_len <= AVX_512bit, "unexpected vector length");

The assert becomes redundant.

src/hotspot/cpu/x86/matcher_x86.hpp line 195:

> 193:       case Op_PopCountVI:
> 194:         return ((ety == T_INT && VM_Version::supports_avx512_vpopcntdq()) ||
> 195:            (is_subword_type(ety) && VM_Version::supports_avx512_bitalg())) ? 0 : 50;

Should be easier to read when the condition is split. E.g.:

if (is_subword_type(ety)) {
  return VM_Version::supports_avx512_bitalg())) ? 0 : 50;
} else {
  assert(ety == T_INT, "sanity"); // for documentation purposes
  return VM_Version::supports_avx512_vpopcntdq() ? 0 : 50;
}

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7953:

> 7951:     StubRoutines::x86::_vector_iota_indices = generate_iota_indices("iota_indices");
> 7952: 
> 7953:     if (UsePopCountInstruction && VM_Version::supports_avx2() && !VM_Version::supports_avx512_vpopcntdq()) {

Why is the LUT unconditionally generated? `UsePopCountInstruction` still guides the usages.

src/hotspot/cpu/x86/vm_version_x86.hpp line 375:

> 373:     decl(RDTSCP,            "rdtscp",            48) /* RDTSCP instruction */ \
> 374:     decl(RDPID,             "rdpid",             49) /* RDPID instruction */ \
> 375:     decl(FSRM,              "fsrm",              50) /* Fast Short REP MOV */ \

`test/lib-test/jdk/test/whitebox/CPUInfoTest.java` should be adjusted as well, shouldn't it?

src/hotspot/cpu/x86/x86.ad line 2113:

> 2111: 
> 2112:     case Op_CountLeadingZerosV:
> 2113:       if ((bt == T_INT || bt == T_LONG) && VM_Version::supports_avx512cd()) {

Newly introduced `is_non_subword_integral_type(bt)` can be used here instead of `bt == T_INT || bt == T_LONG`.

src/hotspot/share/classfile/vmIntrinsics.hpp line 1152:

> 1150:                                       "Ljdk/internal/vm/vector/VectorSupport$ComExpOperation;)"                                                \
> 1151:                                       "Ljdk/internal/vm/vector/VectorSupport$VectorPayload;")                                                  \
> 1152:    do_name(vector_comexp_op_name,     "comExpOp")                                                                                              \

I don't see much value in trying to shorten the name by abbreviating it. I find it easier to read in an expanded form:
` compressExpandOp`, `vector_compress_expand_op_name`, `_VectorCompressExpand`, etc.

src/hotspot/share/opto/c2compiler.cpp line 521:

> 519:     if (!Matcher::match_rule_supported(Op_SignumF)) return false;
> 520:     break;
> 521:   case vmIntrinsics::_VectorComExp:

Why `_VectorComExp` intrinsic is special? Other vector intrinsics are handled later and in a different manner.

What about `ExpandV` case?

src/hotspot/share/opto/compile.cpp line 3416:

> 3414: 
> 3415:   case Op_ReverseBytesV:
> 3416:   case Op_ReverseV: {

Can you elaborate, please, why it is performed so late in the optimization phase (at the very end during graph reshaping) and not during GVN?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From smarks at openjdk.java.net  Fri May 13 00:35:39 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 13 May 2022 00:35:39 GMT
Subject: RFR: 8286393: Address possibly lossy conversions in java.rmi
In-Reply-To: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>
References: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>
Message-ID: <faD4FOV3c-cjiikolW2fWhmoJvtm3X4k0PwIZU9NNbg=.2f9f756e-d45c-45ee-8fe1-e8fe3a781cbe@github.com>

On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599.
> 
> Explicit casts are inserted where implicit casts occur.
> 
> 8286393: Address possibly lossy conversions in java.rmi
> 8286388: Address possibly lossy conversions in java.smartcardio

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8683

From smarks at openjdk.java.net  Fri May 13 00:39:40 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 13 May 2022 00:39:40 GMT
Subject: RFR: 8286393: Address possibly lossy conversions in java.rmi
In-Reply-To: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>
References: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>
Message-ID: <T6csy4G65jaKvFQB__-zxKH-6tXwFFkpFN1Hh0UWDBg=.8219e411-3d1f-4a03-a136-e64e6593f4d7@github.com>

On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599.
> 
> Explicit casts are inserted where implicit casts occur.
> 
> 8286393: Address possibly lossy conversions in java.rmi
> 8286388: Address possibly lossy conversions in java.smartcardio

Reviewed. I also added `noreg-trivial` labels to the bug reports.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8683

From xgong at openjdk.java.net  Fri May 13 01:30:56 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 13 May 2022 01:30:56 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store
In-Reply-To: <h_dBFf-GImm34qGOacTsrYWt73EyjMmzSGDywaytZEA=.6754f31f-23ad-4205-986a-799b594039bc@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <h_dBFf-GImm34qGOacTsrYWt73EyjMmzSGDywaytZEA=.6754f31f-23ad-4205-986a-799b594039bc@github.com>
Message-ID: <ayBtAZlGwsv4c4saOe3z-FvA1eEfHfCbBrmlclhd1cs=.dea29616-fc59-4249-9564-1f2b57c9af72@github.com>

On Thu, 12 May 2022 09:49:17 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Maybe we could use `a.length - vsp.length() > 0 && offset u< a.length - vsp.length()` which would hoist the first check outside of the loop. Thanks.

Thanks for the review @merykitty ! We need the check `offset >= 0` which I think is different from `a.length - vsp.length()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From xgong at openjdk.java.net  Fri May 13 01:35:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 13 May 2022 01:35:40 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v2]
In-Reply-To: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
Message-ID: <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>

> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
> 
> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
> 
> Benchmark                                   Before    After     Gain Units
> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
> 
> Similar performane gain can also be observed on ARM hardware.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Wrap the offset check into a static method

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8620/files
  - new: https://git.openjdk.java.net/jdk/pull/8620/files/eb67f681..2229dd24

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8620&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8620&range=00-01

  Stats: 56 lines in 8 files changed: 5 ins; 0 del; 51 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8620.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8620/head:pull/8620

PR: https://git.openjdk.java.net/jdk/pull/8620

From xgong at openjdk.java.net  Fri May 13 01:35:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 13 May 2022 01:35:40 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v2]
In-Reply-To: <tqNGoFG1OnNbyuQrTu5HsE9_aI8XJR8buJbZxDINVBY=.f65b24f6-1301-452a-8c09-c5fb3f1d8cc5@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <72MBdW0hFE0o2NLg2I94Zw7y-ZJ7-SGVh5Pjz9mmOGI=.31b44f50-547a-4d79-a355-2705d0e8869e@github.com>
 <sJETl1j62ULlycx4Ymmd2uFSjFdA4g0m9mOxuz3SJus=.a587d7a8-5b9f-4f28-bccc-c3bcb36b4e85@github.com>
 <tqNGoFG1OnNbyuQrTu5HsE9_aI8XJR8buJbZxDINVBY=.f65b24f6-1301-452a-8c09-c5fb3f1d8cc5@github.com>
Message-ID: <M8AKg6e74bUcfOZwDVZtL8z2YU5Vrj4P1mT5193hUyY=.cbb2adac-5531-4b38-8e7e-d75f55ad93ac@github.com>

On Thu, 12 May 2022 03:36:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Thanks for the review @PaulSandoz ! For the `VectorIntrinsics.checkFromIndexSize`, I'm afraid it's not suitable to be used here because the `outOfBounds` exception will be thrown if the offset is not inside of the valid array boundary. And  for the masked operations, this is not needed since we only need to check the masked lanes. Please correct me if I didn't understand correctly. Thanks!
>
> Silly me! i commented too quickly, `checkFromIndexSize` cannot be used. My intent was that we could use a method rather than repeating the expression in numerous places (including masked loads IIRC).

Hi @PaulSandoz , I'v updated the offset check for masked load/store. Could you please help to check whether it is ok? Thanks so much!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From xgong at openjdk.java.net  Fri May 13 01:52:44 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 13 May 2022 01:52:44 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
Message-ID: <LAYISxpjCJPFhTOM-ofibCD8yIpmDNQKE4s9jPRe1oA=.8931cb93-7e01-413d-aa57-632ade1e09ca@github.com>

On Thu, 12 May 2022 16:07:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:
> 
> ```
>     719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>   ** missing constant: offsetInRange=Parm
>                             @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation
> ```
> 
> So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).

Make sense to me! I think I understand what you mean. I will have more tests with the integer constant change. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From jpai at openjdk.java.net  Fri May 13 01:59:50 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 13 May 2022 01:59:50 GMT
Subject: RFR: 8286623: Bundle zlib by default with JDK on macos aarch64
In-Reply-To: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
References: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
Message-ID: <eg6oa0mM1gHJ1Z8On__L6JoO5xe6Rd_6zXtV-POrgGU=.16037f2f-8574-4e44-b63a-caa1bffb49d0@github.com>

On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? 
> 
> We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. 
> We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64.

Thank you everyone for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8675

From jpai at openjdk.java.net  Fri May 13 01:59:51 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 13 May 2022 01:59:51 GMT
Subject: Integrated: 8286623: Bundle zlib by default with JDK on macos aarch64
In-Reply-To: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
References: <yXDeNXPyOXPSwn7yHh1tehQj4lUejjLLolmWasKtCIg=.d33792fb-a743-488d-94c2-01957e52dbbf@github.com>
Message-ID: <ZsCnUUmNEyuS73klXwVOk9tlUFupwH-vlKl5qIoA0ZU=.a0c73ae5-eae9-4852-bea6-ab07b7cdcf8b@github.com>

On Thu, 12 May 2022 08:43:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change to the build system which now makes bundled zlib as the default for macos aarch64 systems? 
> 
> We have been running into various intermittent failures on macos aarch64 systems for several months now. After investigation we have been able to ascertain that the root cause of the issue lies within the zlib that's shipped on macos aarch64 systems. The complete details about that issue is available at https://bugs.openjdk.java.net/browse/JDK-8282954. 
> We have filed a bug with Apple for their inputs on what we can do to fix it in that shipped library. Given the nature of that issue, we don't have a timeline on when/if the solution for that will be available. Until that time, at least, the proposal is to use bundled zlib (which doesn't reproduce those failures) by default on macos aarch64.

This pull request has now been integrated.

Changeset: c3bade2e
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c3bade2e08f865bf1e65d48e6d27bff9c022d35f
Stats:     4 lines in 2 files changed: 2 ins; 0 del; 2 mod

8286623: Bundle zlib by default with JDK on macos aarch64

Reviewed-by: lancea, ihse, erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/8675

From duke at openjdk.java.net  Fri May 13 02:10:48 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 13 May 2022 02:10:48 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store
In-Reply-To: <ayBtAZlGwsv4c4saOe3z-FvA1eEfHfCbBrmlclhd1cs=.dea29616-fc59-4249-9564-1f2b57c9af72@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <h_dBFf-GImm34qGOacTsrYWt73EyjMmzSGDywaytZEA=.6754f31f-23ad-4205-986a-799b594039bc@github.com>
 <ayBtAZlGwsv4c4saOe3z-FvA1eEfHfCbBrmlclhd1cs=.dea29616-fc59-4249-9564-1f2b57c9af72@github.com>
Message-ID: <VcYPxOxLHdBbPF5lpVrsvw1EySPsDmu6niCnRhuWLGs=.d547ede9-05e2-4a38-a12d-04026a9f5f9a@github.com>

On Fri, 13 May 2022 01:27:18 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Maybe we could use `a.length - vsp.length() > 0 && offset u< a.length - vsp.length()` which would hoist the first check outside of the loop.
>> Thanks.
>
>> Maybe we could use `a.length - vsp.length() > 0 && offset u< a.length - vsp.length()` which would hoist the first check outside of the loop. Thanks.
> 
> Thanks for the review @merykitty ! We need the check `offset >= 0` which I think is different from `a.length - vsp.length()`.

@XiaohongGong  `a >= 0 && a < b` is the same as `b >= 0 && a u< b`, it is how we are doing range check today. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From duke at openjdk.java.net  Fri May 13 02:37:45 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 13 May 2022 02:37:45 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v2]
In-Reply-To: <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>
Message-ID: <t7LGl5Q8p6BVu4txkAq-X-nZi9cEPlCT-wqxxDNDDEw=.a47e6093-1083-4116-a3de-72185d1df566@github.com>

On Fri, 13 May 2022 01:35:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
>> 
>> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
>> 
>> Benchmark                                   Before    After     Gain Units
>> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
>> 
>> Similar performane gain can also be observed on ARM hardware.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap the offset check into a static method

However, we seem to lack the ability to do an unsigned comparison reliably. C2 can transform `x + MIN_VALUE <=> y + MIN_VALUE` into `x u<=> y` but it will fail if `x` or `y` is an addition with constant in such cases the constants will be merged together. As a result, I think we need an intrinsic for this. `Integer.compareUnsigned` may fit but it manifests the result into an integer register which may lead to suboptimal materialisation of flags, another approach would be to have a separate method `Integer.lessThanUnsigned` which only returns `boolean` and C2 can have better time splitting the boolean comparison through `IfNode`, which will prevent the materialisation of `boolean` values. What do you two think?

I.e, after splitting if through merge point, the shape of `if (Integer.lessThanUnsigned(a, b))` would be transformed from

         a        b
          \      /
            CmpU
             |
            Bool
             |
            If
          /     \
    IfTrue        IfFalse
          \     /
            Region        1        0
                \         |       /
                         Phi         0
                          \         /
                              CmpI

into

         a        b
          \      /
            CmpU

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From jiefu at openjdk.java.net  Fri May 13 02:54:23 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 02:54:23 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case of
 GCCause::_codecache_GC_threshold
Message-ID: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>

Hi all,

Some tests fail with Shenandoah GC after JDK-8282191.
The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
It would be better to fix it.

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - ShenandoahControlThread::request_gc misses the case of GCCause::_codecache_GC_threshold

Changes: https://git.openjdk.java.net/jdk/pull/8691/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8691&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286681
  Stats: 17 lines in 2 files changed: 17 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8691.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8691/head:pull/8691

PR: https://git.openjdk.java.net/jdk/pull/8691

From duke at openjdk.java.net  Fri May 13 04:44:38 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 13 May 2022 04:44:38 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
Message-ID: <cLmCHJfkHXWvySN8LFRcaPuLAztoSevd6DIdtvzf0io=.fa743567-71a4-4392-ad9c-15fa297af6a4@github.com>

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyrights
>   Fixed cast style to add a space after cast, (where consistent with file style)
>   Improved code per review comments in PollSelectors.

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:

> 126:                     // timed poll interrupted so need to adjust timeout
> 127:                     long adjust = System.nanoTime() - startTime;
> 128:                     to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);

This?will?now always?assign a?negative?number to?`to`.

--------------------------------------------------------------------------------

`=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From almatvee at openjdk.java.net  Fri May 13 05:06:21 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 13 May 2022 05:06:21 GMT
Subject: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as
 "damaged" [v2]
In-Reply-To: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
References: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
Message-ID: <HzvrZxGJtxcDjI3LheldtL6R0nduKpmMBtJUMBhZkAU=.e6ae5a48-db6e-4890-b8cb-c7e6a3dc6536@github.com>

> - No changes to code provided by original fix.
>  - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute unsigned code and code should be at least ad hoc signed.
>  - Signing of app bundle produced by AppContentTest.java fails, since it has invalid app bundle structure with added files into Content folder. Thus test is executed but failure is always expected on macOS aarch64.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8277493: [REDO] Quarantined jpackage apps are labeled as "damaged" [v2]

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8527/files
  - new: https://git.openjdk.java.net/jdk/pull/8527/files/c163503a..e71647b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8527&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8527&range=00-01

  Stats: 291 lines in 2 files changed: 20 ins; 219 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8527.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8527/head:pull/8527

PR: https://git.openjdk.java.net/jdk/pull/8527

From almatvee at openjdk.java.net  Fri May 13 05:06:22 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 13 May 2022 05:06:22 GMT
Subject: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as
 "damaged"
In-Reply-To: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
References: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
Message-ID: <cuZtZfMkNemvn_E-XqLPbGXMnzoNMME3O7tCDH3vQ1E=.0d199207-2e9f-4d99-a569-534893152d1f@github.com>

On Wed, 4 May 2022 03:56:10 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - No changes to code provided by original fix.
>  - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute unsigned code and code should be at least ad hoc signed.
>  - Signing of app bundle produced by AppContentTest.java fails, since it has invalid app bundle structure with added files into Content folder. Thus test is executed but failure is always expected on macOS aarch64.

8277493: [REDO] Quarantined jpackage apps are labeled as "damaged" [v2]
 - Modified test to use Parameter instead of Parameters
 - Combined unsignAppBundle(), signAppBundle() and signAdHocAppBundle() into one function to reduce code duplication. Calling signAppBundle() without any identity will result in just unsigning app.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8527

From alanb at openjdk.java.net  Fri May 13 05:56:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 May 2022 05:56:40 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <cLmCHJfkHXWvySN8LFRcaPuLAztoSevd6DIdtvzf0io=.fa743567-71a4-4392-ad9c-15fa297af6a4@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
 <cLmCHJfkHXWvySN8LFRcaPuLAztoSevd6DIdtvzf0io=.fa743567-71a4-4392-ad9c-15fa297af6a4@github.com>
Message-ID: <XvXme83iYSYuslDFTdt1y5LQ7weIPVzTE93S_Lo-pTs=.de0e2e7d-897a-496c-8233-9af9fa9d8353@github.com>

On Fri, 13 May 2022 04:41:03 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyrights
>>   Fixed cast style to add a space after cast, (where consistent with file style)
>>   Improved code per review comments in PollSelectors.
>
> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:
> 
>> 126:                     // timed poll interrupted so need to adjust timeout
>> 127:                     long adjust = System.nanoTime() - startTime;
>> 128:                     to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);
> 
> This?will?now always?assign a?negative?number to?`to`.
> 
> --------------------------------------------------------------------------------
> 
> `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment.

Well spotted, I don't think that change was intentionally.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From duke at openjdk.java.net  Fri May 13 06:30:47 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 13 May 2022 06:30:47 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v3]
In-Reply-To: <_iORn6NU_sX0ffx8xSNHkigSlplyKN58kEJ7pIcxhUo=.79b191fd-edde-40d7-a28c-e6bc82a8e28a@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
 <_iORn6NU_sX0ffx8xSNHkigSlplyKN58kEJ7pIcxhUo=.79b191fd-edde-40d7-a28c-e6bc82a8e28a@github.com>
Message-ID: <FOBBspxhlmCiQkhmXIA9iokMeDM0m_R_e25RVU0XDG4=.21de09e5-8605-4eab-92b2-d84f38d3baae@github.com>

On Thu, 12 May 2022 14:14:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8282662: Revert dubious changes in MethodType
>
> src/java.base/share/classes/sun/security/validator/EndEntityChecker.java line 119:
> 
>> 117:     // TLS key exchange algorithms requiring keyEncipherment key usage
>> 118:     private static final Collection<String> KU_SERVER_ENCRYPTION =
>> 119:         Arrays.asList("RSA");
> 
> I understand that you haven't modified the `KU_SERVER_KEY_AGREEMENT` on line 122 because it has 4 elements. However, these 2 nearby lines using different styles look a little strange to me. Why restrict the number to 0, 1, and 2? If we have defined methods with up to 9 arguments, does that mean the new type is suitable for 9 elements?

The reason is that for the cases of length 0, 1, 2 we don't create underlying array as we do for larger number of elements. In other words when we replace `Arrays.asList()` with `List.of()` we win only for 0, 1 and 2 elements.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From alanb at openjdk.java.net  Fri May 13 06:39:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 May 2022 06:39:49 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
Message-ID: <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>

On Fri, 13 May 2022 02:43:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Some tests fail with Shenandoah GC after JDK-8282191.
> The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

test/jdk/java/foreign/TestIntrinsics.java line 48:

> 46:  *   -XX:+UseShenandoahGC
> 47:  *   TestIntrinsics
> 48:  */

Is this needed? The parameters looks the same as the first test description so if you are testing with +ShenandoahGC then it will run already.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8691

From jiefu at openjdk.java.net  Fri May 13 06:50:52 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 06:50:52 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
Message-ID: <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>

On Fri, 13 May 2022 06:36:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi all,
>> 
>> Some tests fail with Shenandoah GC after JDK-8282191.
>> The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
>> It would be better to fix it.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> test/jdk/java/foreign/TestIntrinsics.java line 48:
> 
>> 46:  *   -XX:+UseShenandoahGC
>> 47:  *   TestIntrinsics
>> 48:  */
> 
> Is this needed? The parameters looks the same as the first test description so if you are testing with +ShenandoahGC then it will run already.

Without `-XX:+UseShenandoahGC`, this bug wouldn't be exposed.

What do you mean by `if you are testing with +ShenandoahGC then it will run already`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8691

From alanb at openjdk.java.net  Fri May 13 06:59:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 May 2022 06:59:48 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
Message-ID: <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>

On Fri, 13 May 2022 06:47:20 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> test/jdk/java/foreign/TestIntrinsics.java line 48:
>> 
>>> 46:  *   -XX:+UseShenandoahGC
>>> 47:  *   TestIntrinsics
>>> 48:  */
>> 
>> Is this needed? The parameters looks the same as the first test description so if you are testing with +ShenandoahGC then it will run already.
>
> Without `-XX:+UseShenandoahGC`, this bug wouldn't be exposed.
> 
> What do you mean by `if you are testing with +ShenandoahGC then it will run already`?

I assume you are running the tests with:
   make run-tests TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" 
in which case, all of the tests you select to run will be run with that GC. 

What you have is not wrong but wouldn't be a better to add a new test to test/hotspot/jtreg/gc rather than relying on test in test/jdk/java/foreign?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8691

From xgong at openjdk.java.net  Fri May 13 07:06:52 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 13 May 2022 07:06:52 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v2]
In-Reply-To: <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>
Message-ID: <gj1BwICvXDL6iMzj2qwvbynVoeOzpO9JWGXGkRkS9PU=.56a0f0da-a619-4760-a93b-805a97c960e1@github.com>

On Fri, 13 May 2022 01:35:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
>> 
>> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
>> 
>> Benchmark                                   Before    After     Gain Units
>> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
>> 
>> Similar performane gain can also be observed on ARM hardware.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap the offset check into a static method

Thanks for the explanation! Yeah, the main problem is Java doesn't have the direct unsigned comparison. We need the function call. From the two ways you provided, I think the second `Integer.lessThanUnsigned` looks better. But I'm not sure whether this could improve the performance a lot, although the first check `a.length - vsp.length() > 0` can be hosited out side of the loop. And this might make the codes more complex for me. Maybe we can do a pre research to find a better implementation to the unsigned comparison first. Do you think so?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From jpai at openjdk.java.net  Fri May 13 07:14:30 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 13 May 2022 07:14:30 GMT
Subject: RFR: 8286559: Re-examine synchronization of mark and reset methods
 on InflaterInputStream [v2]
In-Reply-To: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
References: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
Message-ID: <vIUGW95vCL2b2qYV8amMIKMMyvmRc6XJoEWAN0N1crM=.7bfe3433-10d2-4704-8867-1ab31cd42691@github.com>

> Can I please get a review of this change that addresses https://bugs.openjdk.java.net/browse/JDK-8286559? 
> 
> The commit here removes the `synchronized` on `mark` and `reset` methods of `InflaterInputStream`. The `mark` method is a no-op method and the `reset` method only always throws a `IOException`. So `synchronized` isn't adding any value here. 
> 
> Additionally, the commit does a minor change to the javadoc of these methods to use `@implNote` to describe what the implementation does. Please let me know if the `@implNote` is unnecessary, in which case, I'll revert that part.
> 
> This change is similar to what was recently done for `FilterInputStream` https://github.com/openjdk/jdk/pull/8309 and `PushbackInputStream` https://github.com/openjdk/jdk/pull/8433
> 
> tier1, tier2 and tier3 tests were run and no related failures were noticed.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Incorporate review comment made on CSR by Joe - Change @implNote to @implSpec

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8649/files
  - new: https://git.openjdk.java.net/jdk/pull/8649/files/89de6078..4d406ac0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8649&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8649&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8649.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8649/head:pull/8649

PR: https://git.openjdk.java.net/jdk/pull/8649

From jiefu at openjdk.java.net  Fri May 13 07:16:39 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 07:16:39 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
 <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
Message-ID: <Z0abpxhHnkgX9PqihMQobLhB6nXLfjXDo1B1Xbamgvg=.30a1aa6c-0bd8-4fc4-aa76-a5b3bc79cdae@github.com>

On Fri, 13 May 2022 06:56:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume you are running the tests with: make run-tests TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" in which case, all of the tests you select to run will be run with that GC.

Yes, you're right.

> What you have is not wrong but wouldn't be a better to add a new test to test/hotspot/jtreg/gc rather than relying on test in test/jdk/java/foreign?

I would suggest reusing the existing test in java/foreign.
This is because this bug was first triggered after `Implementation of Foreign Function & Memory API (Preview)` integration.
And I don't want a copy-paste code duplication in a new test file.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8691

From alanb at openjdk.java.net  Fri May 13 07:36:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 May 2022 07:36:40 GMT
Subject: RFR: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec [v2]
In-Reply-To: <-Y_Pqp9Jl0JMpvC3z7-RASDhRSvhOamEZWPh_FUhpkU=.27334dd1-c0cd-46ca-b18f-10bc80444993@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
 <-Y_Pqp9Jl0JMpvC3z7-RASDhRSvhOamEZWPh_FUhpkU=.27334dd1-c0cd-46ca-b18f-10bc80444993@github.com>
Message-ID: <OkMimqbzo3-iH4uo9Zki9EvQ0Q3TIA46C0W0iRiSW0I=.5280fc59-3044-498b-9499-6864b631e587@github.com>

On Thu, 12 May 2022 20:04:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.
>> 
>> The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.
>> 
>> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8663

From alanb at openjdk.java.net  Fri May 13 07:48:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 May 2022 07:48:48 GMT
Subject: RFR: 8286559: Re-examine synchronization of mark and reset methods
 on InflaterInputStream [v2]
In-Reply-To: <vIUGW95vCL2b2qYV8amMIKMMyvmRc6XJoEWAN0N1crM=.7bfe3433-10d2-4704-8867-1ab31cd42691@github.com>
References: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
 <vIUGW95vCL2b2qYV8amMIKMMyvmRc6XJoEWAN0N1crM=.7bfe3433-10d2-4704-8867-1ab31cd42691@github.com>
Message-ID: <7oJJX029NesPa2bjdvJidcmgN7O2CUnPmJJ6SAhQMkI=.d7f83ce1-f351-4fbe-a203-092113a3129e@github.com>

On Fri, 13 May 2022 07:14:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change that addresses https://bugs.openjdk.java.net/browse/JDK-8286559? 
>> 
>> The commit here removes the `synchronized` on `mark` and `reset` methods of `InflaterInputStream`. The `mark` method is a no-op method and the `reset` method only always throws a `IOException`. So `synchronized` isn't adding any value here. 
>> 
>> Additionally, the commit does a minor change to the javadoc of these methods to use `@implNote` to describe what the implementation does. Please let me know if the `@implNote` is unnecessary, in which case, I'll revert that part.
>> 
>> This change is similar to what was recently done for `FilterInputStream` https://github.com/openjdk/jdk/pull/8309 and `PushbackInputStream` https://github.com/openjdk/jdk/pull/8433
>> 
>> tier1, tier2 and tier3 tests were run and no related failures were noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comment made on CSR by Joe - Change @implNote to @implSpec

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8649

From jbhateja at openjdk.java.net  Fri May 13 08:31:09 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 13 May 2022 08:31:09 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v4]
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <9BFz3-71uc1dcsLybF4_IGlQmh43DBdLkI6FEGxKTro=.d020993a-a112-46fe-9902-6c057918b700@github.com>

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8284960: Review comments resolution.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8425/files
  - new: https://git.openjdk.java.net/jdk/pull/8425/files/b021e082..adf205f9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=02-03

  Stats: 121 lines in 49 files changed: 8 ins; 5 del; 108 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425

PR: https://git.openjdk.java.net/jdk/pull/8425

From jbhateja at openjdk.java.net  Fri May 13 08:31:22 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 13 May 2022 08:31:22 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v3]
In-Reply-To: <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
 <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
Message-ID: <Sbf6Rj5Zz8KFJIGpJmdMH9ScVs3CeKgINDk4d8L-nNc=.e259a479-e03f-445a-a641-413fe0183ec8@github.com>

On Thu, 12 May 2022 22:40:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - 8284960: Correcting a typo.
>>  - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - 8284960: AARCH64 backend changes.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...b021e082
>
> src/hotspot/cpu/x86/matcher_x86.hpp line 195:
> 
>> 193:       case Op_PopCountVI:
>> 194:         return ((ety == T_INT && VM_Version::supports_avx512_vpopcntdq()) ||
>> 195:            (is_subword_type(ety) && VM_Version::supports_avx512_bitalg())) ? 0 : 50;
> 
> Should be easier to read when the condition is split. E.g.:
> 
> if (is_subword_type(ety)) {
>   return VM_Version::supports_avx512_bitalg())) ? 0 : 50;
> } else {
>   assert(ety == T_INT, "sanity"); // for documentation purposes
>   return VM_Version::supports_avx512_vpopcntdq() ? 0 : 50;
> }

DONE

> src/hotspot/cpu/x86/vm_version_x86.hpp line 375:
> 
>> 373:     decl(RDTSCP,            "rdtscp",            48) /* RDTSCP instruction */ \
>> 374:     decl(RDPID,             "rdpid",             49) /* RDPID instruction */ \
>> 375:     decl(FSRM,              "fsrm",              50) /* Fast Short REP MOV */ \
> 
> `test/lib-test/jdk/test/whitebox/CPUInfoTest.java` should be adjusted as well, shouldn't it?

Yes, test updated appropriately.

> src/hotspot/share/classfile/vmIntrinsics.hpp line 1152:
> 
>> 1150:                                       "Ljdk/internal/vm/vector/VectorSupport$ComExpOperation;)"                                                \
>> 1151:                                       "Ljdk/internal/vm/vector/VectorSupport$VectorPayload;")                                                  \
>> 1152:    do_name(vector_comexp_op_name,     "comExpOp")                                                                                              \
> 
> I don't see much value in trying to shorten the name by abbreviating it. I find it easier to read in an expanded form:
> ` compressExpandOp`, `vector_compress_expand_op_name`, `_VectorCompressExpand`, etc.

DONE

> src/hotspot/share/opto/c2compiler.cpp line 521:
> 
>> 519:     if (!Matcher::match_rule_supported(Op_SignumF)) return false;
>> 520:     break;
>> 521:   case vmIntrinsics::_VectorComExp:
> 
> Why `_VectorComExp` intrinsic is special? Other vector intrinsics are handled later and in a different manner.
> 
> What about `ExpandV` case?

It was an attempt to facilitate in-lining of these APIs over targets which do not intrinsify them. I agree its not a generic fix since three APIs are piggybacking on same entry point and without the knowledge of opcode it will be inappropriate to take any call at this place, lazy intrinsification gives opportunity for some of the predications to concertize as compilation happens under closed world assumptions.

> src/hotspot/share/opto/compile.cpp line 3416:
> 
>> 3414: 
>> 3415:   case Op_ReverseBytesV:
>> 3416:   case Op_ReverseV: {
> 
> Can you elaborate, please, why it is performed so late in the optimization phase (at the very end during graph reshaping) and not during GVN?

Its more of a chicken-egg problem here, for masked reverse operation, Reverse IR node is followed by a Blend Node, thus in such a case doing an eager Identity transform in Reverse::Identity will not work, also deferring this to blend may also not work since it could be a non-masked reverse operation, we could have handled it as a special case in inline_vector_nary_operation, but handling such special case in final graph reshaping looked more appropriate.

https://github.com/openjdk/panama-vector/pull/182#discussion_r845678080

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From jbhateja at openjdk.java.net  Fri May 13 08:31:24 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 13 May 2022 08:31:24 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v4]
In-Reply-To: <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
 <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
Message-ID: <dKj9d0RwFCkNlTZZ7nFEBu4zl_Wjj5RwRmH7-4q4QXU=.c6086bbc-055c-41e1-ae50-47797aa74b70@github.com>

On Thu, 12 May 2022 22:48:26 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8284960: Review comments resolution.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7953:
> 
>> 7951:     StubRoutines::x86::_vector_iota_indices = generate_iota_indices("iota_indices");
>> 7952: 
>> 7953:     if (UsePopCountInstruction && VM_Version::supports_avx2() && !VM_Version::supports_avx512_vpopcntdq()) {
> 
> Why is the LUT unconditionally generated? `UsePopCountInstruction` still guides the usages.

LUT should be generated only if UsePopCountInsturction is false and iff target does not support necessary features, AVX512POPCNTDQ (for int/long vectors)  and AVX512_BITALG (for sub-word vectors).  Please refer to following discussion where it was suggested to restrict the scope of flag to only scalar popcount operation. 
https://github.com/openjdk/panama-vector/pull/185#discussion_r847758463

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From asotona at openjdk.java.net  Fri May 13 08:32:29 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Fri, 13 May 2022 08:32:29 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v6]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <LWPvsMChniyfkaHPvxdnn1tvOwQkW9MSCwiDoJ_Fm78=.5ca8e192-b796-43d4-a621-0ac58232eae9@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=05
  Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From uschindler at openjdk.java.net  Fri May 13 08:37:17 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 13 May 2022 08:37:17 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
Message-ID: <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>

On Thu, 12 May 2022 15:45:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:
> 
>  - Merge branch 'master' into foreign-preview
>  - Merge branch 'master' into foreign-preview
>  - Fix crashes in heap segment benchmarks due to misaligned access
>  - Merge branch 'master' into foreign-preview
>  - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - Add tests for loaderLookup/restricted method corner cases
>  - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
>    * Tweak restricted method check to work when there's no caller class
>  - Tweak examples in SymbolLookup javadoc
>  - Merge branch 'master' into foreign-preview
>  - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b

Some late comments and suggestions to fix inconsistencies and wrong javadocs.

src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045:

> 1043:      *
> 1044:      * @throws UnsupportedOperationException
> 1045:      *         If an unsupported map mode is specified.

I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below.

As this is already merged, should I open a PR fixing the docs or open an issue?

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164:

> 1162:         }
> 1163:         if (unmapper != null) {
> 1164:             AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size,

When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing:
- New code returning `MemorySegment` uses `unmapper.address()`
- Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields)

Should I open an issue or a PR to fix this (because this is already merged)?

See the mailing list posts:
- https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html
- https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From uschindler at openjdk.java.net  Fri May 13 08:37:18 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 13 May 2022 08:37:18 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
Message-ID: <L_FVGy5JQ9yj8nS1ox1YazCAtVTrQ2qzs5g9qXH0_6w=.7329e26f-389b-4197-a2b9-aaab3228e000@github.com>

On Fri, 13 May 2022 08:25:01 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:
>> 
>>  - Merge branch 'master' into foreign-preview
>>  - Merge branch 'master' into foreign-preview
>>  - Fix crashes in heap segment benchmarks due to misaligned access
>>  - Merge branch 'master' into foreign-preview
>>  - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Add tests for loaderLookup/restricted method corner cases
>>  - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
>>    * Tweak restricted method check to work when there's no caller class
>>  - Tweak examples in SymbolLookup javadoc
>>  - Merge branch 'master' into foreign-preview
>>  - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b
>
> src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045:
> 
>> 1043:      *
>> 1044:      * @throws UnsupportedOperationException
>> 1045:      *         If an unsupported map mode is specified.
> 
> I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below.
> 
> As this is already merged, should I open a PR fixing the docs or open an issue?

This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From xgong at openjdk.java.net  Fri May 13 09:01:49 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 13 May 2022 09:01:49 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v3]
In-Reply-To: <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
 <CRpzjVdjisQbdjYA1-kj4MYCZt6qA45vt0ctVL7Kxp4=.a99d147f-4835-4465-8159-ddd8d7c0f67a@github.com>
 <lnWmjQ6DpdmRfW4RZHftMizu_3hNx-8R99LKpwKbxZI=.01f95c14-2a92-49d6-b1ba-15660c5fbf6f@github.com>
Message-ID: <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com>

On Thu, 12 May 2022 16:07:54 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename "use_predicate" to "needs_predicate"
>
> Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.:
> 
>     719  240    b        jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes)
>   ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it
>   ** missing constant: offsetInRange=Parm
>                             @ 11   jdk.incubator.vector.IntVector::fromArray0Template (22 bytes)   force inline by annotation
> 
> 
> So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant).

You are right @PaulSandoz ! I ran the tests and benchmarks with your patch, and no failure and performance regression are found. I will update the patch soon. Thanks for the help!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8035

From mcimadamore at openjdk.java.net  Fri May 13 09:48:02 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 09:48:02 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <L_FVGy5JQ9yj8nS1ox1YazCAtVTrQ2qzs5g9qXH0_6w=.7329e26f-389b-4197-a2b9-aaab3228e000@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
 <L_FVGy5JQ9yj8nS1ox1YazCAtVTrQ2qzs5g9qXH0_6w=.7329e26f-389b-4197-a2b9-aaab3228e000@github.com>
Message-ID: <n4D_a4kSN6zI5YMGlUqyUhNWS1rANUS5lIUQuMItpgQ=.e68dcf4f-4409-4dd8-83b6-42ba6f485f8e@github.com>

On Fri, 13 May 2022 08:33:11 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045:
>> 
>>> 1043:      *
>>> 1044:      * @throws UnsupportedOperationException
>>> 1045:      *         If an unsupported map mode is specified.
>> 
>> I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below.
>> 
>> As this is already merged, should I open a PR fixing the docs or open an issue?
>
> This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034)

@uschindler - the issue you mention with respect lack of UOE for wrong file system applies to BB as well. I suggest filing an issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Fri May 13 09:48:08 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 09:48:08 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
Message-ID: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com>

On Fri, 13 May 2022 08:29:13 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits:
>> 
>>  - Merge branch 'master' into foreign-preview
>>  - Merge branch 'master' into foreign-preview
>>  - Fix crashes in heap segment benchmarks due to misaligned access
>>  - Merge branch 'master' into foreign-preview
>>  - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - Add tests for loaderLookup/restricted method corner cases
>>  - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI
>>    * Tweak restricted method check to work when there's no caller class
>>  - Tweak examples in SymbolLookup javadoc
>>  - Merge branch 'master' into foreign-preview
>>  - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
>>    
>>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>>  - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b
>
> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164:
> 
>> 1162:         }
>> 1163:         if (unmapper != null) {
>> 1164:             AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size,
> 
> When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing:
> - New code returning `MemorySegment` uses `unmapper.address()`
> - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields)
> 
> Should I open an issue or a PR to fix this (because this is already merged)?
> 
> See the mailing list posts:
> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html
> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html

Please file an RFE. I suspect that there will be more little improvements and consolidation like this we'll want to make to this code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From mcimadamore at openjdk.java.net  Fri May 13 09:54:42 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 09:54:42 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v11]
In-Reply-To: <gWiunLRP5I6LzRaFp8PzTVXg7YNh8jydCMJxYAjNKT4=.68f678bd-0afd-4840-bf79-c4c87b24f01b@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <gWiunLRP5I6LzRaFp8PzTVXg7YNh8jydCMJxYAjNKT4=.68f678bd-0afd-4840-bf79-c4c87b24f01b@github.com>
Message-ID: <7I2_FqR7mCEnQ6rmAuVx8CZ7pDkv3h4WsjE3PRNLy2c=.ae1fc350-06a5-470f-a1f8-1d7ec2682d9d@github.com>

On Thu, 12 May 2022 10:54:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updating naming to more closely follow the spec: total patterns are renamed to unconditional patterns, unrefined is now unguarded.
>  - Case label elements cannot be unguarded if they have a guard of a type different than boolean.

Looks good - left some minor comments and questions.

src/java.base/share/classes/java/lang/MatchException.java line 58:

> 56:      * @param  message the detail message (which is saved for later retrieval
> 57:      *         by the {@link #getMessage()} method).
> 58:      * @param  cause the cause (which is saved for later retrieval by the

This looks odd - it seems like the sentence is like this:

`the cause ( foo ). (bar)`. E.g. the test in parenthesis exceeds the test outside parenthesis by a wide margin. I suggest both here and in the "message" @param to avoid the parenthesis and split the sentence instead. Examples:


* @param  message the detail message. The message is saved for later retrieval
*  by the {@link #getMessage()} method).


and


* @param cause the cause. The cause is saved for later retrieval by the
*  {@link #getCause()} method). A {@code null} value is
* permitted, and indicates that the cause is nonexistent or
* unknown.


Of course this is just an idea.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 177:

> 175:         allowPatternSwitch = (preview.isEnabled() || !preview.isPreview(Feature.PATTERN_SWITCH)) &&
> 176:                              Feature.PATTERN_SWITCH.allowedInSource(source);
> 177:         allowUnconditionalPatternsInstance = (preview.isEnabled() || !preview.isPreview(Feature.UNCONDITIONAL_PATTERN_IN_INSTANCEOF)) &&

Nit: perhaps adding "Of" to this already long variable name doesn't add much in terms of chars, but makes the meaning of the variable name clearer?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1802:

> 1800:                                 unguarded &&
> 1801:                                 !patternType.isErroneous() &&
> 1802:                                 types.isSubtype(types.boxedTypeOrType(types.erasure(seltype)),

This seems to be a change compared to the previous code - e.g. handling of boxing in the switch target type. Is this code even exercised? The test "NotApplicableTypes" seems to rule the combination `switch (int) ... case Integer` out.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java line 1325:

> 1323:     }
> 1324: 
> 1325:     public record PatternPrimaryType(Type type) {}

This is no longer needed - seems just a wrapper around a type.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From xgong at openjdk.java.net  Fri May 13 09:57:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Fri, 13 May 2022 09:57:40 GMT
Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE
 with predicate feature [v4]
In-Reply-To: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
References: <e3CCq1zj5CtcHZIN3EBzJy5-alUOuFyfRVb4k0FGa6s=.05abf6a1-f548-4ba9-a888-14ec5a365da5@github.com>
Message-ID: <5WQ3tKFVgp4s4hW0rMZ4aVOo24I32lsIcrFG2cqkszc=.62ce9cc7-9b41-4a59-adff-cbd50e34069f@github.com>

> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception.
> 
> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize):
> 
> 
>   @ForceInline
>   public static
>   ByteVector fromArray(VectorSpecies<Byte> species,
>                        byte[] a, int offset,
>                        VectorMask<Byte> m) {
>   ByteSpecies vsp = (ByteSpecies) species;
>       if (offset >= 0 && offset <= (a.length - species.length())) {
>           return vsp.dummyVector().fromArray0(a, offset, m);
>       }
> 
>       // FIXME: optimize
>       checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>       return vsp.vOp(m, i -> a[offset + i]);
>   }
> 
> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed.
> 
> Also adds the same vectorization support for masked:
>  - fromByteArray/fromByteBuffer
>  - fromBooleanArray
>  - fromCharArray
> 
> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system:
> 
> Benchmark                                          before   After  Units
> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE    233.816 7075.923 ops/ms
> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
> 
> Similar performance gain can also be observed on 512-bit SVE system.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Use integer constant for offsetInRange all the way through

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8035/files
  - new: https://git.openjdk.java.net/jdk/pull/8035/files/9c69206e..07edfbd5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=02-03

  Stats: 438 lines in 39 files changed: 33 ins; 118 del; 287 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8035.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035

PR: https://git.openjdk.java.net/jdk/pull/8035

From ysuenaga at openjdk.java.net  Fri May 13 10:02:30 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 13 May 2022 10:02:30 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
Message-ID: <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
> 
> * -Wstringop-overflow
>     * src/hotspot/share/oops/array.hpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
> 
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Revert change for java.c , parse_manifest.c , LinuxPackage.c

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8646/files
  - new: https://git.openjdk.java.net/jdk/pull/8646/files/b3afa3e0..d5ef2c63

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=03-04

  Stats: 10 lines in 3 files changed: 1 ins; 4 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646

PR: https://git.openjdk.java.net/jdk/pull/8646

From stuefe at openjdk.java.net  Fri May 13 10:21:48 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 13 May 2022 10:21:48 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
Message-ID: <Oa0E9OEZpABTtFpdieFA2Sh4Tsc4M6QbGM21LXTehNk=.13759647-60f2-4beb-a698-c84477cfcc76@github.com>

On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use stringStream to simplify controller path assembly

Thanks for taking my suggestion! Much simpler now :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From lancea at openjdk.java.net  Fri May 13 10:30:52 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 13 May 2022 10:30:52 GMT
Subject: RFR: 8282648: Problems due to conflicting specification of
 Inflater::inflate(..) and InflaterInputStream::read(..) [v2]
In-Reply-To: <hpt-Q0_errzRUETHJOzF6Ms8kQCNVLLm6Uqoegfy0Ps=.9f40508c-089d-46a3-8cc3-1e8a974f0c7c@github.com>
References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com>
 <u7SmxIfTCznpuW55CMpzxmA1snjfx_zTamEroCwIS1A=.e1c5fb16-b27e-464b-8395-9e580383c0e0@github.com>
 <Yvhoqqm8__c1-DHsMd8orphrRgWeX92WuXGxnPTU-M4=.56898485-2c3f-4155-a93b-c08c886e9b23@github.com>
 <5n-I0E5OO7uAHLo7fWdPqgAojcWpMMIB_AhGrxSKRVA=.a38c974d-eafd-4bbf-85ec-2eb457105b59@github.com>
 <hpt-Q0_errzRUETHJOzF6Ms8kQCNVLLm6Uqoegfy0Ps=.9f40508c-089d-46a3-8cc3-1e8a974f0c7c@github.com>
Message-ID: <ZjtQRQr0I3hRXNGDgGGqdg-cMhUmjolz-4me2lqt9fs=.910a0716-234f-4445-bf14-92582a70cfca@github.com>

On Wed, 30 Mar 2022 10:26:56 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> Hello Volker, An additional thing that we might have to consider here is whether adding this javadoc change to `InflaterInputStream` is ever going to "show up" to end user applications. What I mean is, I think in many cases the end user applications won't even know they are dealing with an `InflaterInputStream`. For example, the following code:
>>> 
>>> ```
>>> ZipFile zf = ...
>>> ZipEntry ze = zf.getEntry("some-file");
>>> InputStream is = zf.getInputStream(ze);
>>> ```
>>> 
>>> As we see above, none of these APIs talk about `InflaterInputStream` (the return type of `ZipFile.getInpustream(...)` is an `InputStream`). So end users won't be able to view this spec change. Perhaps we should also add some note in the `ZipFile.getInpustream(....)` API to make a mention of this potential difference in behaviour of the returned stream?
>> 
>> You are right with your observation and I'll be happy to add a corresponding comment if @LanceAndersen and @AlanBateman agree. Please let me know what you think?
>
>> > Hello Volker, An additional thing that we might have to consider here is whether adding this javadoc change to `InflaterInputStream` is ever going to "show up" to end user applications. What I mean is, I think in many cases the end user applications won't even know they are dealing with an `InflaterInputStream`. For example, the following code:
>> > ```
>> > ZipFile zf = ...
>> > ZipEntry ze = zf.getEntry("some-file");
>> > InputStream is = zf.getInputStream(ze);
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > As we see above, none of these APIs talk about `InflaterInputStream` (the return type of `ZipFile.getInpustream(...)` is an `InputStream`). So end users won't be able to view this spec change. Perhaps we should also add some note in the `ZipFile.getInpustream(....)` API to make a mention of this potential difference in behaviour of the returned stream?
>> 
>> You are right with your observation and I'll be happy to add a corresponding comment if @LanceAndersen and @AlanBateman agree. Please let me know what you think?
> 
> Hi Volker,
> 
> I believe Jai raises a valid point given these javadocs probably have had limited updates if any since the API was originally added.    We should look at ZipInputStream and GZipInputStream as well if we decide to update the ZipFile::getInputStream(where we could borrow some wording from the ZipInputStream class description as a start to some word smithing).
> 
> As Roger points out we will need a release note for this change as well.

> @LanceAndersen, @AlanBateman can you please comment on the [CSR](https://bugs.openjdk.java.net/browse/JDK-8283758) for this issue. We now circled back to the initial proposal in the [CSR](https://bugs.openjdk.java.net/browse/JDK-8283758) but @jddarcy would like to hear your opinion.

Have not forgotten about this.  I think we are not quite there on the changes to` Inputstream` but have not had a chance to give it some more thought.  Apologies and thank you for your patience

-------------

PR: https://git.openjdk.java.net/jdk/pull/7986

From jvernee at openjdk.java.net  Fri May 13 10:40:15 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 May 2022 10:40:15 GMT
Subject: RFR: 8286390: Address possibly lossy conversions in
 jdk.incubator.foreign moved to java.base
Message-ID: <Wg0iUAj6VgPCUV3oTZ1ZD9xRNYAQB5ReMkQOUgYBkzM=.02279d0d-729f-4efc-b0f0-bbb27ba6eeba@github.com>

Address possible lossy conversion warning in `ProgrammableInvoker`.

Testing: `run-test-jdk_foreign`, testing with patch from https://github.com/openjdk/jdk/pull/8599 to see if the warning is gone.

-------------

Commit messages:
 - Address possible lossy conversion warning in ProgrammableInvoker

Changes: https://git.openjdk.java.net/jdk/pull/8697/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8697&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286390
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8697.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8697/head:pull/8697

PR: https://git.openjdk.java.net/jdk/pull/8697

From dfuchs at openjdk.java.net  Fri May 13 11:02:56 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 13 May 2022 11:02:56 GMT
Subject: RFR: 8286390: Address possibly lossy conversions in
 jdk.incubator.foreign moved to java.base
In-Reply-To: <Wg0iUAj6VgPCUV3oTZ1ZD9xRNYAQB5ReMkQOUgYBkzM=.02279d0d-729f-4efc-b0f0-bbb27ba6eeba@github.com>
References: <Wg0iUAj6VgPCUV3oTZ1ZD9xRNYAQB5ReMkQOUgYBkzM=.02279d0d-729f-4efc-b0f0-bbb27ba6eeba@github.com>
Message-ID: <i8wEA6V3rPZMaGhWQP7nEbAydNplEZixwOqjWGHPKL8=.8e2f17e1-6d3b-414f-8ee0-ff412bcf4afb@github.com>

On Fri, 13 May 2022 10:04:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Address possible lossy conversion warning in `ProgrammableInvoker`.
> 
> Testing: `run-test-jdk_foreign`, testing with patch from https://github.com/openjdk/jdk/pull/8599 to see if the warning is gone.

src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java line 215:

> 213:         for (int i = 0; i < highLevelType.parameterCount(); i++) {
> 214:             List<Binding> bindings = callingSequence.argumentBindings(i);
> 215:             argInsertPos += Math.toIntExact(bindings.stream().filter(Binding.VMStore.class::isInstance).count()) + 1;

My gut feeling in this case would be that it's a bit strange to use `Math.toIntExact` to do a safe cast when you don't do `Math.addExact` to ensure that the result of the addition will not overflow. I wonder if a simple cast wouldn't be more appropriate - unless you really think that you might have more than Integer.MAX_VALUE bindings (which I doubt :-) ). But that's just my feeling...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8697

From uschindler at openjdk.java.net  Fri May 13 11:06:12 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 13 May 2022 11:06:12 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
 <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com>
Message-ID: <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com>

On Fri, 13 May 2022 09:43:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164:
>> 
>>> 1162:         }
>>> 1163:         if (unmapper != null) {
>>> 1164:             AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size,
>> 
>> When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing:
>> - New code returning `MemorySegment` uses `unmapper.address()`
>> - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields)
>> 
>> Should I open an issue or a PR to fix this (because this is already merged)?
>> 
>> See the mailing list posts:
>> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html
>> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html
>
> Please file an RFE. I suspect that there will be more little improvements and consolidation like this we'll want to make to this code.

RFE = issue?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From ihse at openjdk.java.net  Fri May 13 11:15:48 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 11:15:48 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <pFAtlj9YmGwoG2a2UprliV_cYJc7Mbv_PGmJh6HR85c=.b69a42c5-2b93-4705-8430-02cabf3c9e1a@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
 <YL_YZOMz5aRKDYJD5THtdj9mOJL54kF2GfTBMA5f20g=.17c024be-503f-407a-8262-2d2ac78480e5@github.com>
 <pFAtlj9YmGwoG2a2UprliV_cYJc7Mbv_PGmJh6HR85c=.b69a42c5-2b93-4705-8430-02cabf3c9e1a@github.com>
Message-ID: <XH96C3BItqkpzE3Tc7zUIEjOspj8cuSgMr4PyhCHpQ8=.300d5982-689f-433d-a668-536a6bf06215@github.com>

On Wed, 27 Apr 2022 16:18:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188:
>> 
>>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757
>>> 187: 
>>> 188: main.plugin.category=\u7C7B\u522B
>> 
>> what's this?
>
> Removing the trailing space? A similar one is in the `ja` resource bundle.

This happens as a combination of jcheck not enforcing eol space checks on .properties files, and my editor being set to always remove space at eol.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From duke at openjdk.java.net  Fri May 13 11:19:51 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 13 May 2022 11:19:51 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v3]
In-Reply-To: <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
Message-ID: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com>

On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282662: Revert dubious changes in MethodType

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727:

> 725:             MethodVisitor mv = cw.visitMethod(accessFlags,
> 726:                     method.getName(), desc, null,
> 727:                     typeNames(List.of(exceptionTypes)));

Since?`exceptionTypes` is?an?array, it?might be?better to?keep?using `Arrays.asList`, or?add an?overload for?`typeNames` that?works on?class?arrays.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From jvernee at openjdk.java.net  Fri May 13 11:23:47 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 May 2022 11:23:47 GMT
Subject: RFR: 8286390: Address possibly lossy conversions in
 jdk.incubator.foreign moved to java.base
In-Reply-To: <i8wEA6V3rPZMaGhWQP7nEbAydNplEZixwOqjWGHPKL8=.8e2f17e1-6d3b-414f-8ee0-ff412bcf4afb@github.com>
References: <Wg0iUAj6VgPCUV3oTZ1ZD9xRNYAQB5ReMkQOUgYBkzM=.02279d0d-729f-4efc-b0f0-bbb27ba6eeba@github.com>
 <i8wEA6V3rPZMaGhWQP7nEbAydNplEZixwOqjWGHPKL8=.8e2f17e1-6d3b-414f-8ee0-ff412bcf4afb@github.com>
Message-ID: <7TJVm4fNp_ZAn32x_FkmX0h1zuW2_gG5Bsz3Q2wrZ0s=.3e9ef34a-86aa-4e27-8f69-ed829efbcee5@github.com>

On Fri, 13 May 2022 10:59:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Address possible lossy conversion warning in `ProgrammableInvoker`.
>> 
>> Testing: `run-test-jdk_foreign`, testing with patch from https://github.com/openjdk/jdk/pull/8599 to see if the warning is gone.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java line 215:
> 
>> 213:         for (int i = 0; i < highLevelType.parameterCount(); i++) {
>> 214:             List<Binding> bindings = callingSequence.argumentBindings(i);
>> 215:             argInsertPos += Math.toIntExact(bindings.stream().filter(Binding.VMStore.class::isInstance).count()) + 1;
> 
> My gut feeling in this case would be that it's a bit strange to use `Math.toIntExact` to do a safe cast when you don't do `Math.addExact` to ensure that the result of the addition will not overflow. I wonder if a simple cast wouldn't be more appropriate - unless you really think that you might have more than Integer.MAX_VALUE bindings (which I doubt :-) ). But that's just my feeling...

Yeah, that's true. I don't really expect this to ever overflow, that would create issues in other cases as well (since the limit on argument count is 255 for instance).

Okay, I'll switch this to a regular cast. (It doesn't matter too much I think because I'm also planning to remove this code: https://github.com/openjdk/jdk/pull/8685)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8697

From ihse at openjdk.java.net  Fri May 13 11:29:46 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 11:29:46 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <VMe3Pe85o_qJoR-Yw5bZ1-GIeqHwyb_V8J-iS78KFlQ=.966dc7fe-0399-4342-94c0-f31f51914fe5@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
 <VMe3Pe85o_qJoR-Yw5bZ1-GIeqHwyb_V8J-iS78KFlQ=.966dc7fe-0399-4342-94c0-f31f51914fe5@github.com>
Message-ID: <CSH7NDI3DpP0NTS6tC-zBUDja8b-4bQZJKOp_wnJPeE=.6b93b153-eb95-42d0-b446-d900498a8448@github.com>

On Wed, 27 Apr 2022 16:50:30 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> src/java.se/share/data/jdwp/jdwp.spec line 47:
> 
>> 45:         "Returns reference types for all the classes loaded by the target VM "
>> 46:         "which match the given signature. "
>> 47:         "Multiple reference types will be returned if two or more class "
> 
> This file's name scares me. The fact that there's no "serviceability" label on this PR adds to this feeling. I would ask around if I were you.

I'll revert all changes in this file. I don't want it to hold up the entire PR. We can revisit it later, with serviceability.

> src/java.sql.rowset/share/classes/com/sun/rowset/JoinRowSetImpl.java line 636:
> 
>> 634:                 // to be INNER JOIN'ED to form a new rowset
>> 635:                 // Compare table1.MatchColumn1.value1 == { table2.MatchColumn2.value1
>> 636:                 //                              ... up to table2.MatchColumn2.valueN }
> 
> Curious: it is not some established string representation, is it?

You mean writing "upto" instead of "up to"? No, it's just incorrect, and a somewhat common typo.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From ihse at openjdk.java.net  Fri May 13 11:35:14 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 11:35:14 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <e6r94NB7QloVJ1ta6wGd2VUTBXfs55PIBjTWAJ3JmAM=.2e7ffc36-11c8-4575-88c8-cf2707dd7f12@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
 <e6r94NB7QloVJ1ta6wGd2VUTBXfs55PIBjTWAJ3JmAM=.2e7ffc36-11c8-4575-88c8-cf2707dd7f12@github.com>
Message-ID: <7kx-jUmt6rUlKn4ca0EfM7oN2HSyM8wtxdENSuL5X-Y=.639d9012-93bf-455e-9a73-6a69412af948@github.com>

On Wed, 27 Apr 2022 15:45:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEventReaderImpl.java line 140:
> 
>> 138:             } else if(type == XMLEvent.START_ELEMENT) {
>> 139:                 throw new XMLStreamException(
>> 140:                 "elementGetText() function expects text only element but START_ELEMENT was encountered.", event.getLocation());
> 
> Should we be fixing typos in third party software; it can easily get wiped out in an update.

No, we should not. Such changes ideally should be brought upstream, but I can't be bothered. :-(

I'm reverting all changes in this file. Are there any more files that are 3rd party in this fix? I have no way to tell.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From ihse at openjdk.java.net  Fri May 13 11:35:19 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 11:35:19 GMT
Subject: RFR: 8285485: Fix typos in corelibs
In-Reply-To: <KVPVwOIG_zdCd2N_xkC72wc1CunMHDZzLyHPuu8W61g=.6aa23c39-701d-46d3-8f1c-9be76215e4ea@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
 <KVPVwOIG_zdCd2N_xkC72wc1CunMHDZzLyHPuu8W61g=.6aa23c39-701d-46d3-8f1c-9be76215e4ea@github.com>
Message-ID: <PNlcstWXKmKF7O-1d_wnLnfi24ZX5_ISGEwWiZcbg24=.90a4cae1-396f-49ed-a067-e1522ac70857@github.com>

On Wed, 27 Apr 2022 17:11:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
>> 
>> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
>> 
>> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.
>
> src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLDOMWriterImpl.java line 238:
> 
>> 236: 
>> 237:     /**
>> 238:      * Creates a DOM Attribute @see org.w3c.dom.Node and associates it with the current DOM element @see org.w3c.dom.Node.
> 
> Not that it matters in this PR, but I think I should mention that `@see` tags do not work like that. (No action needed from you.)

Yeah. There's a lot of crappy code hanging around. :( Feel free to open a bug on checking incorrect usage of `@see` tags in the JDK. I'm sure you'll find more cases than those.

> src/java.xml/share/classes/javax/xml/transform/Transformer.java line 127:
> 
>> 125:      * namespace URI in curly braces ({}).
>> 126:      * @param value The value object.  This can be any valid Java object. It is
>> 127:      * up to the processor to provide the proper object coersion or to simply
> 
> That made me pause: some systems have the notion of _type coercion_; but your change looks right.

I also had to read this a couple of time, and check the source.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From ihse at openjdk.java.net  Fri May 13 11:38:34 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 11:38:34 GMT
Subject: RFR: 8285485: Fix typos in corelibs [v2]
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <KMQ5blCLIF6HuB8pndBabQZelQ7_SEVLT7C4t4Xxr3c=.d401bd78-87de-4804-a18e-571dea1eed77@github.com>

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fixes comments in review:
  
  * Reverting changes in jdwp.spec
  * Fix "is occurs"
  * Stop providing "Syncchronication" providers :-)
  * Fix fEncoder reduplication.
  * Revert changes in XMLEventReaderImpl.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8364/files
  - new: https://git.openjdk.java.net/jdk/pull/8364/files/d4266e0a..b6c00de9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=00-01

  Stats: 13 lines in 6 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8364/head:pull/8364

PR: https://git.openjdk.java.net/jdk/pull/8364

From jlahoda at openjdk.java.net  Fri May 13 11:39:09 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 13 May 2022 11:39:09 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v11]
In-Reply-To: <7I2_FqR7mCEnQ6rmAuVx8CZ7pDkv3h4WsjE3PRNLy2c=.ae1fc350-06a5-470f-a1f8-1d7ec2682d9d@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <gWiunLRP5I6LzRaFp8PzTVXg7YNh8jydCMJxYAjNKT4=.68f678bd-0afd-4840-bf79-c4c87b24f01b@github.com>
 <7I2_FqR7mCEnQ6rmAuVx8CZ7pDkv3h4WsjE3PRNLy2c=.ae1fc350-06a5-470f-a1f8-1d7ec2682d9d@github.com>
Message-ID: <tbb0gQGujOxdc7Z3FJ4tkXUWD5EztmqR4dQvJSSUwSQ=.2c7d87cf-7134-4f2a-b083-21ea04fd29d3@github.com>

On Fri, 13 May 2022 09:29:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updating naming to more closely follow the spec: total patterns are renamed to unconditional patterns, unrefined is now unguarded.
>>  - Case label elements cannot be unguarded if they have a guard of a type different than boolean.
>
> src/java.base/share/classes/java/lang/MatchException.java line 58:
> 
>> 56:      * @param  message the detail message (which is saved for later retrieval
>> 57:      *         by the {@link #getMessage()} method).
>> 58:      * @param  cause the cause (which is saved for later retrieval by the
> 
> This looks odd - it seems like the sentence is like this:
> 
> `the cause ( foo ). (bar)`. E.g. the test in parenthesis exceeds the test outside parenthesis by a wide margin. I suggest both here and in the "message" @param to avoid the parenthesis and split the sentence instead. Examples:
> 
> 
> * @param  message the detail message. The message is saved for later retrieval
> *  by the {@link #getMessage()} method).
> 
> 
> and
> 
> 
> * @param cause the cause. The cause is saved for later retrieval by the
> *  {@link #getCause()} method). A {@code null} value is
> * permitted, and indicates that the cause is nonexistent or
> * unknown.
> 
> 
> Of course this is just an idea.

I believe this text is taken form another exception in java.lang. If that would be OK, I'd look at this in a followup/separate issue.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1802:
> 
>> 1800:                                 unguarded &&
>> 1801:                                 !patternType.isErroneous() &&
>> 1802:                                 types.isSubtype(types.boxedTypeOrType(types.erasure(seltype)),
> 
> This seems to be a change compared to the previous code - e.g. handling of boxing in the switch target type. Is this code even exercised? The test "NotApplicableTypes" seems to rule the combination `switch (int) ... case Integer` out.

Yes, `switch ("int") { case Integer i -> }` is not allowed. The intent of `boxedTypeOrType` is to reduce follow-up errors, as `Integer i` will be considered to be unconditional over `int`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From ihse at openjdk.java.net  Fri May 13 11:45:14 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 11:45:14 GMT
Subject: RFR: 8285485: Fix typos in corelibs [v3]
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <_jkOOYf10_iUXfeN5cffFD7H9WCXQRZVVyfx1kGckS4=.60a50101-35a5-408b-950c-6ebd23c453b4@github.com>

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie 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 six additional commits since the last revision:

 - Merge branch 'master' into typos-in-corelibs
 - Fixes comments in review:
   
   * Reverting changes in jdwp.spec
   * Fix "is occurs"
   * Stop providing "Syncchronication" providers :-)
   * Fix fEncoder reduplication.
   * Revert changes in XMLEventReaderImpl.java
 - Pass #2 core
 - Pass #1 core
 - Pass #2 misc
 - Pass #1 misc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8364/files
  - new: https://git.openjdk.java.net/jdk/pull/8364/files/b6c00de9..8bc35edb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=01-02

  Stats: 228368 lines in 2830 files changed: 173822 ins; 38520 del; 16026 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8364/head:pull/8364

PR: https://git.openjdk.java.net/jdk/pull/8364

From ihse at openjdk.java.net  Fri May 13 11:45:15 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 11:45:15 GMT
Subject: RFR: 8285485: Fix typos in corelibs [v3]
In-Reply-To: <e6r94NB7QloVJ1ta6wGd2VUTBXfs55PIBjTWAJ3JmAM=.2e7ffc36-11c8-4575-88c8-cf2707dd7f12@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
 <e6r94NB7QloVJ1ta6wGd2VUTBXfs55PIBjTWAJ3JmAM=.2e7ffc36-11c8-4575-88c8-cf2707dd7f12@github.com>
Message-ID: <hXufeHEOcSjEkEQTcqCXA8oObmqVNjyxCSh7qlZIqNY=.f9805bb3-9e32-45cf-897d-192cc69f0054@github.com>

On Wed, 27 Apr 2022 15:50:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Magnus Ihse Bursie 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 six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into typos-in-corelibs
>>  - Fixes comments in review:
>>    
>>    * Reverting changes in jdwp.spec
>>    * Fix "is occurs"
>>    * Stop providing "Syncchronication" providers :-)
>>    * Fix fEncoder reduplication.
>>    * Revert changes in XMLEventReaderImpl.java
>>  - Pass #2 core
>>  - Pass #1 core
>>  - Pass #2 misc
>>  - Pass #1 misc
>
> Since you've changed some code; you need to run tests for tiers 1-3.
> 
> (Note that even for trivial changes, hundreds of OpenJDK developers are notified and distracted; be considerate of other developers).

I believe I have addressed all feedback in the review, with the possible exception of 3rd party source. @RogerRiggs Are there more 3rd party files I have inadvertently modified, apart from `XMLEventReaderImpl.java`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From jvernee at openjdk.java.net  Fri May 13 12:06:45 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 May 2022 12:06:45 GMT
Subject: RFR: 8286390: Address possibly lossy conversions in
 jdk.incubator.foreign moved to java.base [v2]
In-Reply-To: <Wg0iUAj6VgPCUV3oTZ1ZD9xRNYAQB5ReMkQOUgYBkzM=.02279d0d-729f-4efc-b0f0-bbb27ba6eeba@github.com>
References: <Wg0iUAj6VgPCUV3oTZ1ZD9xRNYAQB5ReMkQOUgYBkzM=.02279d0d-729f-4efc-b0f0-bbb27ba6eeba@github.com>
Message-ID: <pBpqJm0Qndx-L3vyFaZ_2xJcOyJzGhhWD79owiMrwkQ=.ffd23a65-dd66-4597-9259-a3ac2e8d12bf@github.com>

> Address possible lossy conversion warning in `ProgrammableInvoker`.
> 
> Testing: `run-test-jdk_foreign`, testing with patch from https://github.com/openjdk/jdk/pull/8599 to see if the warning is gone.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Use plain int cast instead

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8697/files
  - new: https://git.openjdk.java.net/jdk/pull/8697/files/da907697..d207f515

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8697&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8697&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8697.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8697/head:pull/8697

PR: https://git.openjdk.java.net/jdk/pull/8697

From jvernee at openjdk.java.net  Fri May 13 12:06:45 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 May 2022 12:06:45 GMT
Subject: RFR: 8286390: Address possibly lossy conversions in
 jdk.incubator.foreign moved to java.base [v2]
In-Reply-To: <7TJVm4fNp_ZAn32x_FkmX0h1zuW2_gG5Bsz3Q2wrZ0s=.3e9ef34a-86aa-4e27-8f69-ed829efbcee5@github.com>
References: <Wg0iUAj6VgPCUV3oTZ1ZD9xRNYAQB5ReMkQOUgYBkzM=.02279d0d-729f-4efc-b0f0-bbb27ba6eeba@github.com>
 <i8wEA6V3rPZMaGhWQP7nEbAydNplEZixwOqjWGHPKL8=.8e2f17e1-6d3b-414f-8ee0-ff412bcf4afb@github.com>
 <7TJVm4fNp_ZAn32x_FkmX0h1zuW2_gG5Bsz3Q2wrZ0s=.3e9ef34a-86aa-4e27-8f69-ed829efbcee5@github.com>
Message-ID: <MbBwxzJrwq2MQgmEGKd4GcrcQKlcb0IlmhjEzwJLmPo=.5a444f02-e195-4548-87a5-6fa5620f9186@github.com>

On Fri, 13 May 2022 11:17:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java line 215:
>> 
>>> 213:         for (int i = 0; i < highLevelType.parameterCount(); i++) {
>>> 214:             List<Binding> bindings = callingSequence.argumentBindings(i);
>>> 215:             argInsertPos += Math.toIntExact(bindings.stream().filter(Binding.VMStore.class::isInstance).count()) + 1;
>> 
>> My gut feeling in this case would be that it's a bit strange to use `Math.toIntExact` to do a safe cast when you don't do `Math.addExact` to ensure that the result of the addition will not overflow. I wonder if a simple cast wouldn't be more appropriate - unless you really think that you might have more than Integer.MAX_VALUE bindings (which I doubt :-) ). But that's just my feeling...
>
> Yeah, that's true. I don't really expect this to ever overflow, that would create issues in other cases as well (since the limit on argument count is 255 for instance).
> 
> Okay, I'll switch this to a regular cast. (It doesn't matter too much I think because I'm also planning to remove this code: https://github.com/openjdk/jdk/pull/8685)

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8697

From mcimadamore at openjdk.java.net  Fri May 13 12:03:01 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 12:03:01 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
 <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com>
 <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com>
Message-ID: <PtbW9tOE_rGlf_ve9Q3zx7oZSWb-GE834deYiwkxZuQ=.cc3375e5-1acd-493d-b25f-ffca1f674e7a@github.com>

On Fri, 13 May 2022 11:01:09 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

> RFE = issue?

issue, with type RFE (request for enhancement)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From uschindler at openjdk.java.net  Fri May 13 12:19:15 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 13 May 2022 12:19:15 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <PtbW9tOE_rGlf_ve9Q3zx7oZSWb-GE834deYiwkxZuQ=.cc3375e5-1acd-493d-b25f-ffca1f674e7a@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
 <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com>
 <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com>
 <PtbW9tOE_rGlf_ve9Q3zx7oZSWb-GE834deYiwkxZuQ=.cc3375e5-1acd-493d-b25f-ffca1f674e7a@github.com>
Message-ID: <DwOTD2DJi_QMv7B0AEkLYGu-QGHhfrwveJtckt9Y_CU=.68ac1153-12aa-4bdf-b5f4-1ed9f09af790@github.com>

On Fri, 13 May 2022 11:59:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> RFE = issue?
>
>> RFE = issue?
> 
> issue, with type RFE (request for enhancement)

See: https://bugs.openjdk.java.net/browse/JDK-8286734

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From duke at openjdk.java.net  Fri May 13 12:23:03 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 13 May 2022 12:23:03 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v3]
In-Reply-To: <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
 <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com>
Message-ID: <FAz94giFgpWhvP92dNc3xetP7uZnL6HFvjm_HIx4-yc=.050146cc-fa6c-4290-a1f0-118bbc79e436@github.com>

On Fri, 13 May 2022 11:14:29 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8282662: Revert dubious changes in MethodType
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727:
> 
>> 725:             MethodVisitor mv = cw.visitMethod(accessFlags,
>> 726:                     method.getName(), desc, null,
>> 727:                     typeNames(List.of(exceptionTypes)));
> 
> Since?`exceptionTypes` is?an?array, it?might be?better to?keep?using `Arrays.asList`, or?add an?overload for?`typeNames` that?works on?class?arrays.

Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From duke at openjdk.java.net  Fri May 13 12:23:04 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 13 May 2022 12:23:04 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v3]
In-Reply-To: <FAz94giFgpWhvP92dNc3xetP7uZnL6HFvjm_HIx4-yc=.050146cc-fa6c-4290-a1f0-118bbc79e436@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
 <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com>
 <FAz94giFgpWhvP92dNc3xetP7uZnL6HFvjm_HIx4-yc=.050146cc-fa6c-4290-a1f0-118bbc79e436@github.com>
Message-ID: <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com>

On Fri, 13 May 2022 12:19:08 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 727:
>> 
>>> 725:             MethodVisitor mv = cw.visitMethod(accessFlags,
>>> 726:                     method.getName(), desc, null,
>>> 727:                     typeNames(List.of(exceptionTypes)));
>> 
>> Since?`exceptionTypes` is?an?array, it?might be?better to?keep?using `Arrays.asList`, or?add an?overload for?`typeNames` that?works on?class?arrays.
>
> Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving

Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From uschindler at openjdk.java.net  Fri May 13 12:29:09 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Fri, 13 May 2022 12:29:09 GMT
Subject: RFR: 8282191: Implementation of Foreign Function & Memory API
 (Preview) [v45]
In-Reply-To: <n4D_a4kSN6zI5YMGlUqyUhNWS1rANUS5lIUQuMItpgQ=.e68dcf4f-4409-4dd8-83b6-42ba6f485f8e@github.com>
References: <ZmzlmmJSYeROyNiF83ZO6_7xcwKJp_g6DAROoWAib4k=.5e758e82-4d11-415e-a0e2-3b75259f4973@github.com>
 <OphEO4AKMyLDb1edi_BtewM8nL-UygwUDl1dEdqk60E=.69ac067a-85f8-4bbf-b8d1-97ffc823704b@github.com>
 <kIFz0NuApwaIIqqc4ZPqhbXEd43AKNyOMb9eF7uf4SA=.2bdff270-4b8e-4f7e-ac91-2e0eef51a2a3@github.com>
 <L_FVGy5JQ9yj8nS1ox1YazCAtVTrQ2qzs5g9qXH0_6w=.7329e26f-389b-4197-a2b9-aaab3228e000@github.com>
 <n4D_a4kSN6zI5YMGlUqyUhNWS1rANUS5lIUQuMItpgQ=.e68dcf4f-4409-4dd8-83b6-42ba6f485f8e@github.com>
Message-ID: <_qJfbHWbWDSXgHQx9PRP2YDQ7cLkC41BmxL_osQIRhs=.dd01fb6e-e671-4bb4-8332-9c9d337abaf9@github.com>

On Fri, 13 May 2022 09:42:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034)
>
> @uschindler - the issue you mention with respect lack of UOE for wrong file system applies to BB as well. I suggest filing an issue.

See https://bugs.openjdk.java.net/browse/JDK-8286735

-------------

PR: https://git.openjdk.java.net/jdk/pull/7888

From zgu at openjdk.java.net  Fri May 13 12:30:03 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 13 May 2022 12:30:03 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
Message-ID: <oZItDX1dvCDJnf1J2750lTdXHAPtPRS7_LUpTPubAsk=.790840bc-d347-40e1-87ed-2f8b8025ff60@github.com>

On Fri, 13 May 2022 02:43:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Some tests fail with Shenandoah GC after JDK-8282191.
> The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

LGTM

-------------

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8691

From mcimadamore at openjdk.java.net  Fri May 13 12:43:27 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 12:43:27 GMT
Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer
Message-ID: <zeaLhFMyC1279aCYqNzyT23OI6AXiUxzkWNS68yJbQs=.55dd8eec-7f94-4897-9cab-2d4485ff05cc@github.com>

This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`.
This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function.

We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`.
So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`.

In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case.

-------------

Commit messages:
 - Tweak javadoc
 - Merge branch 'foreign-preview' into generalize_ofbuffer
 - Merge branch 'master' into foreign-preview
 - Merge branch 'master' into foreign-preview
 - Merge branch 'master' into foreign-preview
 - Fix crashes in heap segment benchmarks due to misaligned access
 - Merge branch 'master' into foreign-preview
 - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java
 - Initial push
 - Add tests for loaderLookup/restricted method corner cases
 - ... and 59 more: https://git.openjdk.java.net/jdk/compare/11fa03f3...02494e2f

Changes: https://git.openjdk.java.net/jdk/pull/8701/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8701&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286715
  Stats: 95 lines in 8 files changed: 55 ins; 1 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8701.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8701/head:pull/8701

PR: https://git.openjdk.java.net/jdk/pull/8701

From mcimadamore at openjdk.java.net  Fri May 13 12:43:28 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 12:43:28 GMT
Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer
In-Reply-To: <zeaLhFMyC1279aCYqNzyT23OI6AXiUxzkWNS68yJbQs=.55dd8eec-7f94-4897-9cab-2d4485ff05cc@github.com>
References: <zeaLhFMyC1279aCYqNzyT23OI6AXiUxzkWNS68yJbQs=.55dd8eec-7f94-4897-9cab-2d4485ff05cc@github.com>
Message-ID: <fQiGMrBY8wSQV0YWdI7sITMVGIvroCz2bHFwtzXK6kg=.4f149e1e-9495-4d40-8902-1163cea751aa@github.com>

On Fri, 13 May 2022 12:33:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`.
> This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function.
> 
> We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`.
> So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`.
> 
> In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case.

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 88:

> 86:  * if it is associated with a confined session, it can only be accessed by the thread which owns the memory session.
> 87:  * <p>
> 88:  * Heap segments are always associated with the {@linkplain MemorySession#global() global} memory session.

I've tweaked this text, as I realized the old version was erroneously suggesting that all buffer segments were backed by a global session.

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 577:

> 575:     }
> 576: 
> 577:     private static int getScaleFactor(Buffer buffer) {

Note: for each buffer kind, there are three possible cases. Consider `IntBuffer`: an `IntBuffer` can be backed by:
* `byte[]`, if it's a byte buffer view
* `int[]`, if it's allocated with `IntBuffer.allocate`, or `IntBuffer.wrap`
* null, if it comes from a direct byte buffer viewed as an `IntBuffer`

As such, the buffer kind (IntBuffer vs. LongBuffer) determines the buffer element size, and therefore how much the buffer position and size should be scaled.

But to check whether we need to create a heap vs. off-heap vs. mapped segment, or to check _which_ kind of heap segment we need, we need to look into the buffer base object, since there can be multiple options for any single buffer type.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8701

From mcimadamore at openjdk.java.net  Fri May 13 12:47:38 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 12:47:38 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
 <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
Message-ID: <e4z5TOmcqmZ9NVTAkksVWVqamxv3_HFl2zNMe0OIl9Y=.af70855b-3c51-4490-baa1-a2df33d85d8f@github.com>

On Fri, 13 May 2022 06:56:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Without `-XX:+UseShenandoahGC`, this bug wouldn't be exposed.
>> 
>> What do you mean by `if you are testing with +ShenandoahGC then it will run already`?
>
> I assume you are running the tests with:
>    make run-tests TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" 
> in which case, all of the tests you select to run will be run with that GC. 
> 
> What you have is not wrong but wouldn't be a better to add a new test to test/hotspot/jtreg/gc rather than relying on test in test/jdk/java/foreign?

I think I agree with @AlanBateman - in the sense that this seems to go down a slippery slope where every test would need to be executed against all possible GCs. AFAIK, there are no other foreign tests doing this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8691

From duke at openjdk.java.net  Fri May 13 12:59:56 2022
From: duke at openjdk.java.net (Shruthi)
Date: Fri, 13 May 2022 12:59:56 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v7]
In-Reply-To: <_UvAX-yqqgkYdqp1UQA0V85qI5HJ-OlCMurpck7Tu2U=.902f5630-a4bb-4340-b061-7cdc63c0851e@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <-r3ALnm_qKjys-U2GxzdJykWJUglWqMdBglBPdmiBKs=.b8664eec-5cdc-4e6c-85f4-6c48bd393d78@github.com>
 <_UvAX-yqqgkYdqp1UQA0V85qI5HJ-OlCMurpck7Tu2U=.902f5630-a4bb-4340-b061-7cdc63c0851e@github.com>
Message-ID: <VQx0CLrHvdb21X4NSTFcuV-YiKNUfrvOEw2-btOE7rA=.e6b15e5f-0825-46d8-bd24-81942d612330@github.com>

On Thu, 12 May 2022 15:51:15 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Shruthi has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> Copyright years for XRTreeFragSelectWrapper.java and XSLTErrorResources.java were still not updated, with the later missing the LastModified tag. Please double check all files before integrate.

@JoeWang-Java
 Added Copyright header year and Last-Modified tag, with this commit the test is failing could you please suggest the same

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From jiefu at openjdk.java.net  Fri May 13 13:04:54 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 13:04:54 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
 <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
Message-ID: <l9GDU4cf8hShYEZQSSEDcT06L7hy0X_OA5oTnvqaE14=.214889fc-f64b-486b-baa4-6435495736c9@github.com>

On Fri, 13 May 2022 06:56:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Without `-XX:+UseShenandoahGC`, this bug wouldn't be exposed.
>> 
>> What do you mean by `if you are testing with +ShenandoahGC then it will run already`?
>
> I assume you are running the tests with:
>    make run-tests TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" 
> in which case, all of the tests you select to run will be run with that GC. 
> 
> What you have is not wrong but wouldn't be a better to add a new test to test/hotspot/jtreg/gc rather than relying on test in test/jdk/java/foreign?

> I think I agree with @AlanBateman - in the sense that this seems to go down a slippery slope where every test would need to be executed against all possible GCs. AFAIK, there are no other foreign tests doing this.

I think it's a waste of time to write a separate test for this bug.

I can't understand why you are against adding one more test config in the foreign test.
Yes, it caught the bug in ShenandoahGC but who knows it wouldn't find some other bugs in the foreign api in the future.
If you are still against the newly added test config, I can revert the test change.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8691

From dfuchs at openjdk.java.net  Fri May 13 13:06:55 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 13 May 2022 13:06:55 GMT
Subject: RFR: 8286390: Address possibly lossy conversions in
 jdk.incubator.foreign moved to java.base [v2]
In-Reply-To: <pBpqJm0Qndx-L3vyFaZ_2xJcOyJzGhhWD79owiMrwkQ=.ffd23a65-dd66-4597-9259-a3ac2e8d12bf@github.com>
References: <Wg0iUAj6VgPCUV3oTZ1ZD9xRNYAQB5ReMkQOUgYBkzM=.02279d0d-729f-4efc-b0f0-bbb27ba6eeba@github.com>
 <pBpqJm0Qndx-L3vyFaZ_2xJcOyJzGhhWD79owiMrwkQ=.ffd23a65-dd66-4597-9259-a3ac2e8d12bf@github.com>
Message-ID: <B1Xv3BmjrJIQQh8ZxKrDbTBsxL67Fjypk-0I_YGRtNs=.82700739-f084-48b8-9c39-c441d81c2b66@github.com>

On Fri, 13 May 2022 12:06:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Address possible lossy conversion warning in `ProgrammableInvoker`.
>> 
>> Testing: `run-test-jdk_foreign`, testing with patch from https://github.com/openjdk/jdk/pull/8599 to see if the warning is gone.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use plain int cast instead

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8697

From dholmes at openjdk.java.net  Fri May 13 13:22:03 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 13 May 2022 13:22:03 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold
In-Reply-To: <l9GDU4cf8hShYEZQSSEDcT06L7hy0X_OA5oTnvqaE14=.214889fc-f64b-486b-baa4-6435495736c9@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
 <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
 <l9GDU4cf8hShYEZQSSEDcT06L7hy0X_OA5oTnvqaE14=.214889fc-f64b-486b-baa4-6435495736c9@github.com>
Message-ID: <UqAfRsN__XAfIiFzDPC97JaTPEnzbc2z_-EvZZwv0v8=.be68a0af-21af-4ef1-9078-50fcc259eaff@github.com>

On Fri, 13 May 2022 13:02:52 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> I assume you are running the tests with:
>>    make run-tests TEST_OPTS_JAVA_OPTIONS="-XX:+UseShenandoahGC" 
>> in which case, all of the tests you select to run will be run with that GC. 
>> 
>> What you have is not wrong but wouldn't be a better to add a new test to test/hotspot/jtreg/gc rather than relying on test in test/jdk/java/foreign?
>
>> I think I agree with @AlanBateman - in the sense that this seems to go down a slippery slope where every test would need to be executed against all possible GCs. AFAIK, there are no other foreign tests doing this.
> 
> I think it's a waste of time to write a separate test for this bug.
> 
> I can't understand why you are against adding one more test config in the foreign test.
> Yes, it caught the bug in ShenandoahGC but who knows it wouldn't find some other bugs in the foreign api in the future.
> If you are still against the newly added test config, I can revert the test change.
> Thanks.

My comment seems to have never made it through. The problem with what your are doing is two-fold:
1. When running the test suite specifically to test xGC for whatever x you are now forcing a test run for Shenandoah.
2.  When x is Shenandoah then you run this test twice.

You don't need a config just to run this with Shenandoah - you run the test suite with Shenandoah.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8691

From jvernee at openjdk.java.net  Fri May 13 13:23:41 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 May 2022 13:23:41 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v2]
In-Reply-To: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
Message-ID: <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com>

> Hi,
> 
> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8685/files
  - new: https://git.openjdk.java.net/jdk/pull/8685/files/6e038edf..80640bac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=00-01

  Stats: 22 lines in 1 file changed: 12 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8685.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8685/head:pull/8685

PR: https://git.openjdk.java.net/jdk/pull/8685

From duke at openjdk.java.net  Fri May 13 13:41:48 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 13 May 2022 13:41:48 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v3]
In-Reply-To: <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
 <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com>
 <FAz94giFgpWhvP92dNc3xetP7uZnL6HFvjm_HIx4-yc=.050146cc-fa6c-4290-a1f0-118bbc79e436@github.com>
 <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com>
Message-ID: <lB5ub_ZJTwl8kSN6S7PBAa1FS66R68ztr_rIaMB3UAQ=.bf5d56f5-1efd-4a8f-8cdd-8dfb095fc647@github.com>

On Fri, 13 May 2022 12:19:25 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving
>
> Usually a method declares either no exception, or a couple of them. In the first case `List.of()` doesn't allocate, in the second it allocates an object with 1-2 fields but without an array, so `List.of()` is likely to be more memory-saving

Even?in the?no?exceptions?case, the?`exceptionTypes`?array still?has to?be?allocated/copied by?`Method.getExceptionTypes()`[^1] when?the?`ProxyMethod`?constructor[^2] is?invoked.

So?if?anything, the?`List.of(?)`?call should?be?moved into?the?`ProxyMethod`?constructor.
And?maybe the?call to?`Method.getExceptionTypes()` should?be?changed to?`Method.getSharedExceptionTypes()`[^3].

[^1]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L340-L343
[^2]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L710-L714
[^3]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L305-L308

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From jiefu at openjdk.java.net  Fri May 13 13:48:43 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 13:48:43 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold [v2]
In-Reply-To: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
Message-ID: <2yg0dzjun8djDothlefQppcbc72bruuLiM6T_5y-WDw=.3acc77a0-2b39-4afb-8c80-b823dfc83f86@github.com>

> Hi all,
> 
> Some tests fail with Shenandoah GC after JDK-8282191.
> The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Revert the test change

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8691/files
  - new: https://git.openjdk.java.net/jdk/pull/8691/files/8f094d32..dc96246c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8691&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8691&range=00-01

  Stats: 15 lines in 1 file changed: 0 ins; 15 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8691.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8691/head:pull/8691

PR: https://git.openjdk.java.net/jdk/pull/8691

From jiefu at openjdk.java.net  Fri May 13 13:48:44 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 13 May 2022 13:48:44 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold [v2]
In-Reply-To: <UqAfRsN__XAfIiFzDPC97JaTPEnzbc2z_-EvZZwv0v8=.be68a0af-21af-4ef1-9078-50fcc259eaff@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <xN5MPm5ZqEM1gMQKDRUqYSxA9_zYtraV5V_ZoacwsbM=.0e2665e2-1dd7-4ec4-8029-5fe239207295@github.com>
 <KixBGOrfFb0-8jKAuTUwkGynHDfHkKytw8Ctk4v20qo=.dd10208d-8a78-407b-8447-682947fe3bc4@github.com>
 <iTeD_uVu2xbCkRxDUSLOVlpHeOVWwLsgQ7Cpz9aFON0=.7de7a475-7038-41c5-9aad-3e252c6420ce@github.com>
 <l9GDU4cf8hShYEZQSSEDcT06L7hy0X_OA5oTnvqaE14=.214889fc-f64b-486b-baa4-6435495736c9@github.com>
 <UqAfRsN__XAfIiFzDPC97JaTPEnzbc2z_-EvZZwv0v8=.be68a0af-21af-4ef1-9078-50fcc259eaff@github.com>
Message-ID: <oZphkb9JhnvZQEGRsDybsPaiInE6d8RQPi_4LhilZWM=.a718bcd0-f0a7-462a-818a-bc153e2f92b3@github.com>

On Fri, 13 May 2022 13:18:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I think I agree with @AlanBateman - in the sense that this seems to go down a slippery slope where every test would need to be executed against all possible GCs. AFAIK, there are no other foreign tests doing this.
>> 
>> I think it's a waste of time to write a separate test for this bug.
>> 
>> I can't understand why you are against adding one more test config in the foreign test.
>> Yes, it caught the bug in ShenandoahGC but who knows it wouldn't find some other bugs in the foreign api in the future.
>> If you are still against the newly added test config, I can revert the test change.
>> Thanks.
>
> My comment seems to have never made it through. The problem with what your are doing is two-fold:
> 1. When running the test suite specifically to test xGC for whatever x you are now forcing a test run for Shenandoah.
> 2.  When x is Shenandoah then you run this test twice.
> 
> You don't need a config just to run this with Shenandoah - you run the test suite with Shenandoah.

The test change had been reverted.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8691

From ihse at openjdk.java.net  Fri May 13 14:08:31 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 14:08:31 GMT
Subject: RFR: 8285485: Fix typos in corelibs [v4]
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <pRZ0yuAuYR5ETZgZDss2BYjlELGJ4K1V6RnuTPnpwr4=.b3ff5bc3-d7b7-47d1-9bdd-eb0f6f99aab0@github.com>

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8364/files
  - new: https://git.openjdk.java.net/jdk/pull/8364/files/8bc35edb..7dc7f653

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8364&range=02-03

  Stats: 86 lines in 86 files changed: 0 ins; 0 del; 86 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8364/head:pull/8364

PR: https://git.openjdk.java.net/jdk/pull/8364

From ysuenaga at openjdk.java.net  Fri May 13 14:16:07 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 13 May 2022 14:16:07 GMT
Subject: RFR: 8286705: GCC 12 reports use-after-free potential bugs
Message-ID: <XWaHVowJNTNpM09udI33X6K22npPRvmIBXjSPoP_h_k=.7204a69a-7d80-47ee-99b1-83371278339a@github.com>

GCC 12 reports use-after-free potential bugs in below:


In function 'find_positions',
    inlined from 'find_file' at /home/ysuenaga/github-forked/jdk/src/java.base/share/native/libjli/parse_manifest.c:364:9:

-------------

Commit messages:
 - 8286705: GCC 12 reports use-after-free potential bugs

Changes: https://git.openjdk.java.net/jdk/pull/8696/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8696&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286705
  Stats: 8 lines in 2 files changed: 4 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8696.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8696/head:pull/8696

PR: https://git.openjdk.java.net/jdk/pull/8696

From ysuenaga at openjdk.java.net  Fri May 13 14:17:11 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 13 May 2022 14:17:11 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher
Message-ID: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>

GCC 12 reports as following:

-------------

Commit messages:
 - 8286694: Incorrect argument processing in java launcher

Changes: https://git.openjdk.java.net/jdk/pull/8694/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8694&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286694
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8694.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8694/head:pull/8694

PR: https://git.openjdk.java.net/jdk/pull/8694

From ysuenaga at openjdk.java.net  Fri May 13 14:17:44 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 13 May 2022 14:17:44 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
Message-ID: <zhVvnKBq9ZmWbtJNECzMr9q7Mf4LbY1I2AzPTci2T5E=.50e074a2-3ce1-4ff9-a4bb-9d7e118e8d4f@github.com>

On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change for java.c , parse_manifest.c , LinuxPackage.c

I've sent another review request for bug fixes as #8694 and #8696 , and I reverted change for them from this PR.
Could you review this PR to suppress warnings which we can ignore?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From rriggs at openjdk.java.net  Fri May 13 14:22:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 13 May 2022 14:22:01 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <XvXme83iYSYuslDFTdt1y5LQ7weIPVzTE93S_Lo-pTs=.de0e2e7d-897a-496c-8233-9af9fa9d8353@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
 <cLmCHJfkHXWvySN8LFRcaPuLAztoSevd6DIdtvzf0io=.fa743567-71a4-4392-ad9c-15fa297af6a4@github.com>
 <XvXme83iYSYuslDFTdt1y5LQ7weIPVzTE93S_Lo-pTs=.de0e2e7d-897a-496c-8233-9af9fa9d8353@github.com>
Message-ID: <gaOBL7rhdMjOzXkN6Iz7MS2jF9EPmevOf5Km6r7m5_A=.c3a4e357-8354-435b-8119-8626d83c941b@github.com>

On Fri, 13 May 2022 05:54:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:
>> 
>>> 126:                     // timed poll interrupted so need to adjust timeout
>>> 127:                     long adjust = System.nanoTime() - startTime;
>>> 128:                     to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);
>> 
>> This?will?now always?assign a?negative?number to?`to`.
>> 
>> --------------------------------------------------------------------------------
>> 
>> `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment.
>
> Well spotted, I don't think that change was intentionally.

Ouch; Will fix:

I took Alan's earlier comment literally:

"This one can also be changed to:

to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From jpai at openjdk.java.net  Fri May 13 14:26:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 13 May 2022 14:26:40 GMT
Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to collect
 data due to permission issues
Message-ID: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>

Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS?

As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command.

Tested locally on macOS by running:


cd test/failure_handler
make clean
make test

Then checked the generated environment.html files for the dmesg command output. Looks fine after this change.

-------------

Commit messages:
 - 8286744: use sudo dmesg on macos for failure handler

Changes: https://git.openjdk.java.net/jdk/pull/8703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8703&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286744
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8703/head:pull/8703

PR: https://git.openjdk.java.net/jdk/pull/8703

From duke at openjdk.java.net  Fri May 13 14:27:02 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 13 May 2022 14:27:02 GMT
Subject: RFR: 8286378: Address possibly lossy conversions in java.base [v3]
In-Reply-To: <gaOBL7rhdMjOzXkN6Iz7MS2jF9EPmevOf5Km6r7m5_A=.c3a4e357-8354-435b-8119-8626d83c941b@github.com>
References: <EamPjhnuxeugBqwvMh8kiciVaKiFBK1lXdxvOGihduQ=.df21d3a9-e0a8-4783-b9dd-b77925da7d89@github.com>
 <MJBpF_-oXSM3jzqmSBHSBTvUTGt9C1UNF60RnvcK7Yw=.85a86ddd-918e-4c7d-84f6-e750d369a515@github.com>
 <cLmCHJfkHXWvySN8LFRcaPuLAztoSevd6DIdtvzf0io=.fa743567-71a4-4392-ad9c-15fa297af6a4@github.com>
 <XvXme83iYSYuslDFTdt1y5LQ7weIPVzTE93S_Lo-pTs=.de0e2e7d-897a-496c-8233-9af9fa9d8353@github.com>
 <gaOBL7rhdMjOzXkN6Iz7MS2jF9EPmevOf5Km6r7m5_A=.c3a4e357-8354-435b-8119-8626d83c941b@github.com>
Message-ID: <uHzo-PzwaY50_BXGNi9Uyfs0a3Y3jiqJ4vcmzEAK5uA=.8a0281d4-3836-43ab-978c-4e6bb5b5a0c3@github.com>

On Fri, 13 May 2022 14:18:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Well spotted, I don't think that change was intentionally.
>
> Ouch; Will fix:
> 
> I took Alan's earlier comment literally:
> 
> "This one can also be changed to:
> 
> to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);"

@RogerRiggs
This?already got?fixed by?@jaikiran in?[GH?8693].

[GH?8693]: https://github.com/openjdk/jdk/pull/8693

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From mcimadamore at openjdk.java.net  Fri May 13 14:35:50 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 14:35:50 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v11]
In-Reply-To: <tbb0gQGujOxdc7Z3FJ4tkXUWD5EztmqR4dQvJSSUwSQ=.2c7d87cf-7134-4f2a-b083-21ea04fd29d3@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <gWiunLRP5I6LzRaFp8PzTVXg7YNh8jydCMJxYAjNKT4=.68f678bd-0afd-4840-bf79-c4c87b24f01b@github.com>
 <7I2_FqR7mCEnQ6rmAuVx8CZ7pDkv3h4WsjE3PRNLy2c=.ae1fc350-06a5-470f-a1f8-1d7ec2682d9d@github.com>
 <tbb0gQGujOxdc7Z3FJ4tkXUWD5EztmqR4dQvJSSUwSQ=.2c7d87cf-7134-4f2a-b083-21ea04fd29d3@github.com>
Message-ID: <6ocyE93x80LXAYdSTOTQkeTAAaqY2wr-xxC5wu8hesY=.b51814ef-a663-434f-8eb3-ac0e1b2f435d@github.com>

On Fri, 13 May 2022 11:34:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/MatchException.java line 58:
>> 
>>> 56:      * @param  message the detail message (which is saved for later retrieval
>>> 57:      *         by the {@link #getMessage()} method).
>>> 58:      * @param  cause the cause (which is saved for later retrieval by the
>> 
>> This looks odd - it seems like the sentence is like this:
>> 
>> `the cause ( foo ). (bar)`. E.g. the test in parenthesis exceeds the test outside parenthesis by a wide margin. I suggest both here and in the "message" @param to avoid the parenthesis and split the sentence instead. Examples:
>> 
>> 
>> * @param  message the detail message. The message is saved for later retrieval
>> *  by the {@link #getMessage()} method).
>> 
>> 
>> and
>> 
>> 
>> * @param cause the cause. The cause is saved for later retrieval by the
>> *  {@link #getCause()} method). A {@code null} value is
>> * permitted, and indicates that the cause is nonexistent or
>> * unknown.
>> 
>> 
>> Of course this is just an idea.
>
> I believe this text is taken form another exception in java.lang. If that would be OK, I'd look at this in a followup/separate issue.

ok!

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1802:
>> 
>>> 1800:                                 unguarded &&
>>> 1801:                                 !patternType.isErroneous() &&
>>> 1802:                                 types.isSubtype(types.boxedTypeOrType(types.erasure(seltype)),
>> 
>> This seems to be a change compared to the previous code - e.g. handling of boxing in the switch target type. Is this code even exercised? The test "NotApplicableTypes" seems to rule the combination `switch (int) ... case Integer` out.
>
> Yes, `switch ("int") { case Integer i -> }` is not allowed. The intent of `boxedTypeOrType` is to reduce follow-up errors, as `Integer i` will be considered to be unconditional over `int`.

Good - I suspected it had to do with error recovery - but wanted to make sure I didn't miss anything.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From dfuchs at openjdk.java.net  Fri May 13 14:39:44 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 13 May 2022 14:39:44 GMT
Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to
 collect data due to permission issues [v2]
In-Reply-To: <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>
References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>
 <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>
Message-ID: <L6p27hd7Qm99O1W1YERm78SlMMilofP-xocaAxRiyVQ=.1340f15f-b18c-4cb1-b81c-edca271632a7@github.com>

On Fri, 13 May 2022 14:36:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS?
>> 
>> As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command.
>> 
>> Tested locally on macOS by running:
>> 
>> 
>> cd test/failure_handler
>> make clean
>> make test
>> 
>> Then checked the generated environment.html files for the dmesg command output. Looks fine after this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8703

From jpai at openjdk.java.net  Fri May 13 14:39:44 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 13 May 2022 14:39:44 GMT
Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to
 collect data due to permission issues [v2]
In-Reply-To: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>
References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>
Message-ID: <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>

> Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS?
> 
> As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command.
> 
> Tested locally on macOS by running:
> 
> 
> cd test/failure_handler
> make clean
> make test
> 
> Then checked the generated environment.html files for the dmesg command output. Looks fine after this change.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8703/files
  - new: https://git.openjdk.java.net/jdk/pull/8703/files/db538083..f85acab5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8703&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8703&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8703/head:pull/8703

PR: https://git.openjdk.java.net/jdk/pull/8703

From rriggs at openjdk.java.net  Fri May 13 14:43:52 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 13 May 2022 14:43:52 GMT
Subject: Integrated: 8286393: Address possibly lossy conversions in java.rmi
In-Reply-To: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>
References: <TpxKr29t6vPpJOgSjzRD79NSiTHJtj3_rRRIPZYL8Gk=.dc332baa-0609-4099-b60f-34192840da6b@github.com>
Message-ID: <80bLg-vrdH0f0tm8xBx_Cv9uHyLfeRKaY1PYD44wSe4=.95ad8079-cbe0-4416-a051-cb7722b1ef34@github.com>

On Thu, 12 May 2022 16:47:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Updates to modules java.rmi and java.smartcardio to remove warnings about lossy-conversions introduced by PR#8599.
> 
> Explicit casts are inserted where implicit casts occur.
> 
> 8286393: Address possibly lossy conversions in java.rmi
> 8286388: Address possibly lossy conversions in java.smartcardio

This pull request has now been integrated.

Changeset: 237f2801
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/237f28014ab9d27d2cdfe3fdc4a5b0a0680f8e95
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8286393: Address possibly lossy conversions in java.rmi
8286388: Address possibly lossy conversions in java.smartcardio

Reviewed-by: lancea, dfuchs, smarks

-------------

PR: https://git.openjdk.java.net/jdk/pull/8683

From jlahoda at openjdk.java.net  Fri May 13 14:58:42 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 13 May 2022 14:58:42 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v12]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <xkl5A1n_rE_EWFwFf0XeEdoRbdP950QIUVMgaO5zrlY=.185cc82a-fca9-4a4d-be3e-84eb7b27023c@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup as suggested on the PR review.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/b0fb8dcd..e903084a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=10-11

  Stats: 14 lines in 4 files changed: 0 ins; 4 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From jvernee at openjdk.java.net  Fri May 13 15:10:57 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 May 2022 15:10:57 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v2]
In-Reply-To: <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com>
Message-ID: <cHLJknMpFeu0fLYry9HJmP2thqDQPWK4wcotcYZGC5I=.9ee66090-3904-4727-bede-e8489c9221eb@github.com>

On Fri, 13 May 2022 13:23:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change)

I seem to have found the issue. One required change was not included brought over from panama-foreign yet. I've included it now, so this should be ready for review. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From asemenyuk at openjdk.java.net  Fri May 13 15:14:41 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 13 May 2022 15:14:41 GMT
Subject: RFR: 8277493: [REDO] Quarantined jpackage apps are labeled as
 "damaged" [v2]
In-Reply-To: <HzvrZxGJtxcDjI3LheldtL6R0nduKpmMBtJUMBhZkAU=.e6ae5a48-db6e-4890-b8cb-c7e6a3dc6536@github.com>
References: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
 <HzvrZxGJtxcDjI3LheldtL6R0nduKpmMBtJUMBhZkAU=.e6ae5a48-db6e-4890-b8cb-c7e6a3dc6536@github.com>
Message-ID: <PH60xKtvY05nBMmWaS9LfnP94wF5NicdIEr77OxUlPs=.28eda43f-fdf0-454c-b6ca-0903eee0a652@github.com>

On Fri, 13 May 2022 05:06:21 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - No changes to code provided by original fix.
>>  - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute unsigned code and code should be at least ad hoc signed.
>>  - Signing of app bundle produced by AppContentTest.java fails, since it has invalid app bundle structure with added files into Content folder. Thus test is executed but failure is always expected on macOS aarch64.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277493: [REDO] Quarantined jpackage apps are labeled as "damaged" [v2]

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8527

From mcimadamore at openjdk.java.net  Fri May 13 15:23:51 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 15:23:51 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v12]
In-Reply-To: <xkl5A1n_rE_EWFwFf0XeEdoRbdP950QIUVMgaO5zrlY=.185cc82a-fca9-4a4d-be3e-84eb7b27023c@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
 <xkl5A1n_rE_EWFwFf0XeEdoRbdP950QIUVMgaO5zrlY=.185cc82a-fca9-4a4d-be3e-84eb7b27023c@github.com>
Message-ID: <gaqoFsXMZi25Uz1KTtgG_uhr3K9i8rHqTgSYj-cuW5Q=.f21d56c3-d9fd-4871-971b-313ae505c225@github.com>

On Fri, 13 May 2022 14:58:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
>> 
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>> 
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
>> 
>> Feedback is welcome!
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup as suggested on the PR review.

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From rriggs at openjdk.java.net  Fri May 13 15:25:42 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 13 May 2022 15:25:42 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v19]
In-Reply-To: <KarZng8o7H5bPfvRdG5L__rxnzB0etngvUrGY_D37rY=.178edfdc-2332-4e41-a702-d43743be6a1c@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <KarZng8o7H5bPfvRdG5L__rxnzB0etngvUrGY_D37rY=.178edfdc-2332-4e41-a702-d43743be6a1c@github.com>
Message-ID: <Khz4ymduoCIYSBZftB3ONNixm3F1b2oR34_nHJN8bS8=.016fda8c-03c9-4b05-ab02-28d1f621055e@github.com>

On Tue, 3 May 2022 21:35:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add mask values to constants' javadoc.

This seems to have reached a stable plateau.
The CSR should have another reviewer.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7445

From darcy at openjdk.java.net  Fri May 13 17:00:55 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 13 May 2022 17:00:55 GMT
Subject: Integrated: JDK-8286604: Update InputStream and OutputStream to use
 @implSpec
In-Reply-To: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
References: <RQxxm7xuiUCayuJnML3nKSFz3gthnfWymwxF-9aIz4M=.b21d7b81-a01b-4b2c-b86f-1784cd959b21@github.com>
Message-ID: <Cuh8pdzyeKIEJ4QEvpOjwdJDeUdmk_q52UMHHc--ULk=.a8d627c7-7c83-48c5-abf1-42e1e2b53a91@github.com>

On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags.
> 
> The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605

This pull request has now been integrated.

Changeset: 1e843c3d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1e843c3d4fbc0b68eceec17be29186dcb5b37de1
Stats:     40 lines in 2 files changed: 18 ins; 9 del; 13 mod

8286604: Update InputStream and OutputStream to use @implSpec

Reviewed-by: bpb, lancea, iris, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8663

From naoto at openjdk.java.net  Fri May 13 17:13:14 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 13 May 2022 17:13:14 GMT
Subject: RFR: 8286399: Address possibly lossy conversions in JDK Build Tools
Message-ID: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com>

Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch.

-------------

Commit messages:
 - 8286399: Address possibly lossy conversions in JDK Build Tools

Changes: https://git.openjdk.java.net/jdk/pull/8706/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8706&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286399
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8706.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8706/head:pull/8706

PR: https://git.openjdk.java.net/jdk/pull/8706

From rriggs at openjdk.java.net  Fri May 13 17:22:50 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 13 May 2022 17:22:50 GMT
Subject: RFR: 8286399: Address possibly lossy conversions in JDK Build
 Tools
In-Reply-To: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com>
References: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com>
Message-ID: <78raR4MgM0oU5wO6qNbEDCWXDOzqnvewaglma5odWNw=.231c3b94-aaa6-4662-8174-9f849ec6a23c@github.com>

On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8706

From itakiguchi at openjdk.java.net  Fri May 13 17:38:48 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 13 May 2022 17:38:48 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v8]
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <L1PK61h3l9Oykbzpg0UXFu8v1cA2pJqjxaxs-zFHW60=.75aad5fe-1814-4b1f-8660-68afe1928e63@github.com>

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8378/files
  - new: https://git.openjdk.java.net/jdk/pull/8378/files/6dbaa751..12018014

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8378&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8378&range=06-07

  Stats: 72 lines in 3 files changed: 10 ins; 2 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8378/head:pull/8378

PR: https://git.openjdk.java.net/jdk/pull/8378

From duke at openjdk.java.net  Fri May 13 17:41:59 2022
From: duke at openjdk.java.net (Markus KARG)
Date: Fri, 13 May 2022 17:41:59 GMT
Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream
 should override transferTo [v13]
In-Reply-To: <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <VCG1Jak1a8dGYUa0MO3F_uL7HMKHd3x4elJ3SlmO-MQ=.2b563685-efea-4e60-a44a-12697ac6a9f7@github.com>
Message-ID: <8Dg7c3PUuuiJEPM6wWrl2LqBaagl0tz-jRXynJYA3do=.731b1132-0a19-4579-9dc6-aceaa21c8b8e@github.com>

On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Draft: Eliminated duplicate code using lambda expressions
>  - Draft: Use blocking mode also for target channel

Please keep this PR open; I will continune work on it soon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From itakiguchi at openjdk.java.net  Fri May 13 17:43:02 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Fri, 13 May 2022 17:43:02 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
 <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
Message-ID: <TMRk8vnq-XLdKfFFCv9TQ8QXwmjvS7628HX6N6z574c=.8b9190a9-3704-4dbc-a36a-ff0a1c40aa44@github.com>

On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> Can you clarify the use of different charset properties for the ProcessEnvironment vs the CommandLine strings?
> 
> They are used to decode or encode strings in the APIs to native functions respectively.
> If I understand `native.encoding` was introduced to reflect the default encoding of file contents, while `sun.jnu.encoding` is used to encode filenames.
> 
> I think I would have expected to see `sun.jnu.encoding` to be used in all contexts when encoding/decoding strings to the native representations.  (Assuming its not required for backward compatibility).

Hello @RogerRiggs and @naotoj .
I modified `ProcessEnvironment.java`and `ProcessImpl.java`.
`i18nEnvArg.java` checks return code instead of string detection.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From duke at openjdk.java.net  Fri May 13 17:43:05 2022
From: duke at openjdk.java.net (Markus KARG)
Date: Fri, 13 May 2022 17:43:05 GMT
Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5]
In-Reply-To: <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
References: <nCH2Jjmn9-24YI7-ZyXUH_z0XxK6YbEc2mTVWBIdWO4=.94ac886d-b55c-4aa9-bcc5-66fa23dbb207@github.com>
 <ZgOSlE0-1thQUJ2l90Exh0uHujmbCRLkeOxpVMaoaRo=.78e967da-6edc-4a4e-be34-73af811bf109@github.com>
Message-ID: <EXMg_27PLJpd7xUZf4id6kaUE_nSfh6WqDAAXr0SD8Y=.a0e5080c-866d-49c0-962f-c7c8a1bea6aa@github.com>

On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> Implementation of JDK-8279283
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed missing BufferedInputStream

Please keep this PR open; I will continune work on it soon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6935

From lancea at openjdk.java.net  Fri May 13 17:46:47 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 13 May 2022 17:46:47 GMT
Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to
 collect data due to permission issues [v2]
In-Reply-To: <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>
References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>
 <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>
Message-ID: <QHG3Dn43vSTWUuU5naPPYQ0uBPjL_SJaPltzIb9GIlc=.44192752-82a1-4ade-8b56-361a9d3abc8a@github.com>

On Fri, 13 May 2022 14:39:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS?
>> 
>> As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command.
>> 
>> Tested locally on macOS by running:
>> 
>> 
>> cd test/failure_handler
>> make clean
>> make test
>> 
>> Then checked the generated environment.html files for the dmesg command output. Looks fine after this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

looks ok to me

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8703

From duke at openjdk.java.net  Fri May 13 17:54:06 2022
From: duke at openjdk.java.net (Piotr Tarsa)
Date: Fri, 13 May 2022 17:54:06 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <Qe0gyxT2wBb49m8qhDLGfzW_4zRLWCIIKuyU4Gl1aTU=.faebadab-9822-48ec-9f31-8b499bf768dc@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

allocating extra buffers and catching OOME when sorting primitives is rather unsatisfactory. you're not giving a reliable option for sorting under low memory conditions. IMO at least the single-threaded primitives (ints, longs, floats, etc all non-objects) sorting should be frugal when it comes to memory usage.

just my 2 cents.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From duke at openjdk.java.net  Fri May 13 17:54:41 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 13 May 2022 17:54:41 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v13]
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <v-ACCo5_ys245ndytutE_XzATk1FkFW0YhCYq7VcpZU=.8bc5a46a-29ad-4160-9882-b86154717e64@github.com>

> Hello,
> 
> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
> 
> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
> 
> 
> Greetings
> Raffaello

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  4511638: Double.toString(double) sometimes produces incorrect results

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3402/files
  - new: https://git.openjdk.java.net/jdk/pull/3402/files/b40d7e80..31ca4e10

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=11-12

  Stats: 54 lines in 4 files changed: 0 ins; 0 del; 54 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402

PR: https://git.openjdk.java.net/jdk/pull/3402

From naoto at openjdk.java.net  Fri May 13 18:40:50 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 13 May 2022 18:40:50 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v8]
In-Reply-To: <L1PK61h3l9Oykbzpg0UXFu8v1cA2pJqjxaxs-zFHW60=.75aad5fe-1814-4b1f-8660-68afe1928e63@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <L1PK61h3l9Oykbzpg0UXFu8v1cA2pJqjxaxs-zFHW60=.75aad5fe-1814-4b1f-8660-68afe1928e63@github.com>
Message-ID: <9uYukMkKKeD4KCdJamFXCQ3izhcDC2XBqV-QknU9Z1Y=.84a824f8-e319-4af1-9c92-c5fc2bc4565c@github.com>

On Fri, 13 May 2022 17:38:48 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 251:

> 249: 
> 250:     /**
> 251:      * Return the {@code sun.jnu.encoding} system property.

This can be eliminated by changing the`@return` block tag below to `{@return the {@code sun.jnu.encoding} ...}`.

src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 264:

> 262: 
> 263:     /**
> 264:      * Return charset for {@code sun.jnu.encoding} system property.

Same as above. `charset` can be capitalized and changed to `{@code}`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From almatvee at openjdk.java.net  Fri May 13 18:42:47 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 13 May 2022 18:42:47 GMT
Subject: Integrated: 8277493: [REDO] Quarantined jpackage apps are labeled as
 "damaged"
In-Reply-To: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
References: <dmFrhOK9XymkuX6fSUpRiIuDpuGDROWaOSBAaWTjDLc=.1756de3d-de1c-44c3-ac26-83f8b9c8c1a6@github.com>
Message-ID: <DybsqGQ7rmsOXpj9NrXTIqioqIxjKrYrr1FKMbJvYDk=.9f9ab444-a7a2-4947-81a1-39b04dd945bf@github.com>

On Wed, 4 May 2022 03:56:10 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - No changes to code provided by original fix.
>  - Added ad hoc signing on macOS aarch64, since macOS aarch64 cannot execute unsigned code and code should be at least ad hoc signed.
>  - Signing of app bundle produced by AppContentTest.java fails, since it has invalid app bundle structure with added files into Content folder. Thus test is executed but failure is always expected on macOS aarch64.

This pull request has now been integrated.

Changeset: 273c7329
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/273c7329e7dff6e97ffe5b299a6bbb5de8ea9190
Stats:     159 lines in 4 files changed: 64 ins; 49 del; 46 mod

8277493: [REDO] Quarantined jpackage apps are labeled as "damaged"

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/8527

From joehw at openjdk.java.net  Fri May 13 18:54:46 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 13 May 2022 18:54:46 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
Message-ID: <ZbzIYm_ACXidlRDyVYZ8H73rZmx11NBW9zntTUW-PpM=.e0cab1f9-9b45-4e41-a53b-56fd7e14d8f9@github.com>

On Thu, 12 May 2022 18:02:26 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi 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:
> 
>   Modify copyright year

Did you mean the failure (Pre-submit tests - Linux x86 - Test (tier1) ) above?  That's not related to your change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From bpb at openjdk.java.net  Fri May 13 19:12:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 13 May 2022 19:12:36 GMT
Subject: RFR: 8286559: Re-examine synchronization of mark and reset methods
 on InflaterInputStream [v2]
In-Reply-To: <vIUGW95vCL2b2qYV8amMIKMMyvmRc6XJoEWAN0N1crM=.7bfe3433-10d2-4704-8867-1ab31cd42691@github.com>
References: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
 <vIUGW95vCL2b2qYV8amMIKMMyvmRc6XJoEWAN0N1crM=.7bfe3433-10d2-4704-8867-1ab31cd42691@github.com>
Message-ID: <rvbkwSI-Zhv3qPElXdIN87v0PrDyf5ezeQkJW7R9m3I=.198f21bc-8f2c-4fc7-9a01-d5697bfe0791@github.com>

On Fri, 13 May 2022 07:14:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change that addresses https://bugs.openjdk.java.net/browse/JDK-8286559? 
>> 
>> The commit here removes the `synchronized` on `mark` and `reset` methods of `InflaterInputStream`. The `mark` method is a no-op method and the `reset` method only always throws a `IOException`. So `synchronized` isn't adding any value here. 
>> 
>> Additionally, the commit does a minor change to the javadoc of these methods to use `@implNote` to describe what the implementation does. Please let me know if the `@implNote` is unnecessary, in which case, I'll revert that part.
>> 
>> This change is similar to what was recently done for `FilterInputStream` https://github.com/openjdk/jdk/pull/8309 and `PushbackInputStream` https://github.com/openjdk/jdk/pull/8433
>> 
>> tier1, tier2 and tier3 tests were run and no related failures were noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comment made on CSR by Joe - Change @implNote to @implSpec

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8649

From vlivanov at openjdk.java.net  Fri May 13 19:17:46 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 13 May 2022 19:17:46 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
 <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
 <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>
 <T73dHwsxmGWzDhJzzaLzEkOpsi6LB7jHBwcBI-JTJlY=.3929d080-0ae2-4645-88db-f5dfa8f0e855@github.com>
 <AIN9VRXcDj-YKtSkychFW7_ZqXdx3AsWmeMnvzJchl8=.680b9133-929d-4a47-809a-2a654a94bf26@github.com>
 <WCNDNQabM_3gZBaog255y0LSokj044con0d23ZeQ7hA=.cfae3ed7-b420-47fc-bf73-f7f65cddf385@github.com>
 <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com>
 <vO8ppClc_A5MhswLQXuTi-T2_3RAoTg6X69
 O1sbQVI8=.15e3f5c1-7bed-4d73-a703-e3737b9f3a4a@github.com>
 <i3sR3qKBIRAlzLMcpbq7kgWfv7b2T9O-KCPXlEljb-0=.fe5edce0-91fb-4549-a8e1-f36cfa549ddc@github.com>
 <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com>
Message-ID: <dNCZmPk9TQEb8P9ID6TH_zCWrQxEtpBEWaAAL9DLOnw=.6bf4496d-a372-4ed7-bb9b-1fde09700dce@github.com>

On Thu, 12 May 2022 17:26:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated.
>> 
>> My understanding is that if they materialize while we're executing the upcall Java code, if that code has a try/catch block, we will go there, rather than crash the VM.
>> 
>> In other words, IMHO the only problem with async exception is if they occur _after_ the Java user code has completed, because that will crash the Java adapter, this preventing it from returning to native call cleanly.
>> 
>> So, either we disable async exceptions during that phase (e.g. after user code has executed, but before we return back to native code), or we just punt and stop. Since this seems like a corner^3 case, and since there are also other issue with upcalls that can occur if other threads do not cooperate (e.g. an upcall can get stuck into an infinite safepoint if the VM exits while an async native thread runs the upcall), and given that obtaining a linker is a restricted operation anyway, I don't think we should bend over backwards to try to add 1% more safety to something that's unavoidably sharp anyways.
>
> Ok. Then, if no one objects, I will leave this area as-is for now. (and perhaps come back to this issue in the future, if it becomes more pressing).
> 
> (I'll also note that this issue already exists in the current code that's in mainline. So, it seems fair to address this as a followup as well, if needed).

I don't see a way to reliably handle async exceptions purely with `try/catch`. In the end, there's always a safepoint poll right before returning from a method where new exception can be installed. So, there's always a small chance present to observe a pending exception on VM side irrespective of how hard you try on Java side. 

>From reliability perspective, I find it important to gracefully handle such corner cases. But I'm fine with addressing the problem separately.

As an alternative solution, exception handling for upcalls can be handled by another upcall (into catch handler when pending exception is encountered). As a bonus, it allows to handle repeated exceptions. In the worst case, it would manifest as a hang (when async exceptions are continuously delivered). Still, some special handling is needed for stack overflow errors. (Not sure how those are handled now. Are they?)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From vlivanov at openjdk.java.net  Fri May 13 19:24:41 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 13 May 2022 19:24:41 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v17]
In-Reply-To: <v-RW6Kh99Q2WigOra-aW599y5SrU145TK7TMD2qSSCA=.18c31c72-4e2d-435d-93a0-f0fa0f515287@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <v-RW6Kh99Q2WigOra-aW599y5SrU145TK7TMD2qSSCA=.18c31c72-4e2d-435d-93a0-f0fa0f515287@github.com>
Message-ID: <gaECJdWy6Wz3Iq9TjrvIx-GC3aW6PYJld5tXRDVXy0Q=.a8d11c61-0208-4090-8986-051ae2345641@github.com>

On Thu, 12 May 2022 16:58:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
>> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
>> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
>> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits:
> 
>  - Merge branch 'master' into JEP-19-VM-IMPL2
>  - Undo spurious changes.
>  - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2
>  - Apply copyright year updates per request of @nick-arm
>    
>    Co-authored-by: Nick Gasson <nick.gasson at arm.com>
>  - Fix overwritten copyright years.
>  - Missed 2 years
>  - Update Oracle copyright years
>  - Revert "Block async exceptions during upcalls"
>    
>    This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790.
>  - Block async exceptions during upcalls
>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>  - ... and 88 more: https://git.openjdk.java.net/jdk/compare/2c5d1362...f55b6c59

Looks good.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531:

> 5529: }
> 5530: 
> 5531: // On64 bit we will store integer like items to the stack as

Missing space.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933:

> 931:     } else {
> 932:       assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)",
> 933:         src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name());

Still not indented properly.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Fri May 13 20:03:11 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 May 2022 20:03:11 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v17]
In-Reply-To: <gaECJdWy6Wz3Iq9TjrvIx-GC3aW6PYJld5tXRDVXy0Q=.a8d11c61-0208-4090-8986-051ae2345641@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <v-RW6Kh99Q2WigOra-aW599y5SrU145TK7TMD2qSSCA=.18c31c72-4e2d-435d-93a0-f0fa0f515287@github.com>
 <gaECJdWy6Wz3Iq9TjrvIx-GC3aW6PYJld5tXRDVXy0Q=.a8d11c61-0208-4090-8986-051ae2345641@github.com>
Message-ID: <kpyT8uDWQ5v897Z7fsiin-pq0kPUXsn4XIppcDKGkSw=.8442cd6f-a88c-446d-b207-7b49498101cf@github.com>

On Fri, 13 May 2022 19:16:36 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits:
>> 
>>  - Merge branch 'master' into JEP-19-VM-IMPL2
>>  - Undo spurious changes.
>>  - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2
>>  - Apply copyright year updates per request of @nick-arm
>>    
>>    Co-authored-by: Nick Gasson <nick.gasson at arm.com>
>>  - Fix overwritten copyright years.
>>  - Missed 2 years
>>  - Update Oracle copyright years
>>  - Revert "Block async exceptions during upcalls"
>>    
>>    This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790.
>>  - Block async exceptions during upcalls
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - ... and 88 more: https://git.openjdk.java.net/jdk/compare/2c5d1362...f55b6c59
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531:
> 
>> 5529: }
>> 5530: 
>> 5531: // On64 bit we will store integer like items to the stack as
> 
> Missing space.

Oh, looks like i deleted the wrong space by accident.

> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933:
> 
>> 931:     } else {
>> 932:       assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)",
>> 933:         src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name());
> 
> Still not indented properly.

Shouldn't there be a 2-space indentation wrt the assert here? I could also indent all the arguments to be aligned with the format string, if that seems better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Fri May 13 20:15:47 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 May 2022 20:15:47 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v7]
In-Reply-To: <dNCZmPk9TQEb8P9ID6TH_zCWrQxEtpBEWaAAL9DLOnw=.6bf4496d-a372-4ed7-bb9b-1fde09700dce@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <CeDBp2LH50FwRZeYk8y3gvztmC0w0_ZLgZMNTZRAqcs=.7e6b6ac7-2e02-4766-b29c-990039903a57@github.com>
 <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com>
 <yklNgohhvBKeO5zf2AP1Yjl9S_GAhG37URLfDiOxwEk=.ab6559ad-89ac-4a02-bb4b-0f6f19d8356e@github.com>
 <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com>
 <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com>
 <T73dHwsxmGWzDhJzzaLzEkOpsi6LB7jHBwcBI-JTJlY=.3929d080-0ae2-4645-88db-f5dfa8f0e855@github.com>
 <AIN9VRXcDj-YKtSkychFW7_ZqXdx3AsWmeMnvzJchl8=.680b9133-929d-4a47-809a-2a654a94bf26@github.com>
 <WCNDNQabM_3gZBaog255y0LSokj044con0d23ZeQ7hA=.cfae3ed7-b420-47fc-bf73-f7f65cddf385@github.com>
 <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com>
 <vO8ppClc_A5MhswLQXuTi-T2_3RAoTg6X69
 O1sbQVI8=.15e3f5c1-7bed-4d73-a703-e3737b9f3a4a@github.com>
 <i3sR3qKBIRAlzLMcpbq7kgWfv7b2T9O-KCPXlEljb-0=.fe5edce0-91fb-4549-a8e1-f36cfa549ddc@github.com>
 <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com>
 <dNCZmPk9TQEb8P9ID6TH_zCWrQxEtpBEWaAAL9DLOnw=.6bf4496d-a372-4ed7-bb9b-1fde09700dce@github.com>
Message-ID: <NRDn8AacN-M_4htAqjesFzrdx_uL5NZPx04wj72tEPc=.473353a7-c7f5-4db7-a113-1e42f34c3e04@github.com>

On Fri, 13 May 2022 19:13:46 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Ok. Then, if no one objects, I will leave this area as-is for now. (and perhaps come back to this issue in the future, if it becomes more pressing).
>> 
>> (I'll also note that this issue already exists in the current code that's in mainline. So, it seems fair to address this as a followup as well, if needed).
>
> I don't see a way to reliably handle async exceptions purely with `try/catch`. In the end, there's always a safepoint poll right before returning from a method where new exception can be installed. So, there's always a small chance present to observe a pending exception on VM side irrespective of how hard you try on Java side. 
> 
> From reliability perspective, I find it important to gracefully handle such corner cases. But I'm fine with addressing the problem separately.
> 
> As an alternative solution, exception handling for upcalls can be handled by another upcall (into catch handler when pending exception is encountered). As a bonus, it allows to handle repeated exceptions. In the worst case, it would manifest as a hang (when async exceptions are continuously delivered). Still, some special handling is needed for stack overflow errors. (Not sure how those are handled now. Are they?)

SOE (of the Java exception kind) is not specially handled right now. I think the same rule applies there: we can't unwind or return to native frames (at least not without some guidance from the user).

I've filed an issue here to capture some of the discussion: https://bugs.openjdk.java.net/browse/JDK-8286761

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From vlivanov at openjdk.java.net  Fri May 13 20:50:46 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 13 May 2022 20:50:46 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v17]
In-Reply-To: <kpyT8uDWQ5v897Z7fsiin-pq0kPUXsn4XIppcDKGkSw=.8442cd6f-a88c-446d-b207-7b49498101cf@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <v-RW6Kh99Q2WigOra-aW599y5SrU145TK7TMD2qSSCA=.18c31c72-4e2d-435d-93a0-f0fa0f515287@github.com>
 <gaECJdWy6Wz3Iq9TjrvIx-GC3aW6PYJld5tXRDVXy0Q=.a8d11c61-0208-4090-8986-051ae2345641@github.com>
 <kpyT8uDWQ5v897Z7fsiin-pq0kPUXsn4XIppcDKGkSw=.8442cd6f-a88c-446d-b207-7b49498101cf@github.com>
Message-ID: <TyiETsSHn9AydXEopgFpQUq79B5_6-2daWD4CHt2mYU=.c74ea49e-5973-41ee-8417-46b8a641fb56@github.com>

On Fri, 13 May 2022 19:59:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933:
>> 
>>> 931:     } else {
>>> 932:       assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)",
>>> 933:         src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name());
>> 
>> Still not indented properly.
>
> Shouldn't there be a 2-space indentation wrt the assert here? I could also indent all the arguments to be aligned with the format string, if that seems better.

It's preferred to indent multi-line argument lists on the column where argument list starts.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From vlivanov at openjdk.java.net  Fri May 13 20:50:46 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 13 May 2022 20:50:46 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v17]
In-Reply-To: <TyiETsSHn9AydXEopgFpQUq79B5_6-2daWD4CHt2mYU=.c74ea49e-5973-41ee-8417-46b8a641fb56@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <v-RW6Kh99Q2WigOra-aW599y5SrU145TK7TMD2qSSCA=.18c31c72-4e2d-435d-93a0-f0fa0f515287@github.com>
 <gaECJdWy6Wz3Iq9TjrvIx-GC3aW6PYJld5tXRDVXy0Q=.a8d11c61-0208-4090-8986-051ae2345641@github.com>
 <kpyT8uDWQ5v897Z7fsiin-pq0kPUXsn4XIppcDKGkSw=.8442cd6f-a88c-446d-b207-7b49498101cf@github.com>
 <TyiETsSHn9AydXEopgFpQUq79B5_6-2daWD4CHt2mYU=.c74ea49e-5973-41ee-8417-46b8a641fb56@github.com>
Message-ID: <qXmbLfSYRgtpMtm5nnb2m6zCJItAxQbhwh-ReDDxetw=.b1a674c5-c00f-4a44-bbfc-c0e34d66193f@github.com>

On Fri, 13 May 2022 20:46:19 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Shouldn't there be a 2-space indentation wrt the assert here? I could also indent all the arguments to be aligned with the format string, if that seems better.
>
> It's preferred to indent multi-line argument lists on the column where argument list starts.

assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)",
       src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name());

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Fri May 13 21:01:10 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 May 2022 21:01:10 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v18]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <mEJrQV1GB6sh3vOVBa3UzgonCWGzmRn7ee7H4cLaSmw=.a46fec95-21c0-492b-b1f6-3eb02b6ed736@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - indentation
 - fix space

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/f55b6c59..2ea5bc94

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=16-17

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Fri May 13 21:01:11 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 May 2022 21:01:11 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v18]
In-Reply-To: <qXmbLfSYRgtpMtm5nnb2m6zCJItAxQbhwh-ReDDxetw=.b1a674c5-c00f-4a44-bbfc-c0e34d66193f@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <v-RW6Kh99Q2WigOra-aW599y5SrU145TK7TMD2qSSCA=.18c31c72-4e2d-435d-93a0-f0fa0f515287@github.com>
 <gaECJdWy6Wz3Iq9TjrvIx-GC3aW6PYJld5tXRDVXy0Q=.a8d11c61-0208-4090-8986-051ae2345641@github.com>
 <kpyT8uDWQ5v897Z7fsiin-pq0kPUXsn4XIppcDKGkSw=.8442cd6f-a88c-446d-b207-7b49498101cf@github.com>
 <TyiETsSHn9AydXEopgFpQUq79B5_6-2daWD4CHt2mYU=.c74ea49e-5973-41ee-8417-46b8a641fb56@github.com>
 <qXmbLfSYRgtpMtm5nnb2m6zCJItAxQbhwh-ReDDxetw=.b1a674c5-c00f-4a44-bbfc-c0e34d66193f@github.com>
Message-ID: <xv5onA5BlgTrzvAox2rFImOYdpV4dV7m4FPgEENMHbA=.b2870d04-f8ca-4261-9094-76e4c4bb3381@github.com>

On Fri, 13 May 2022 20:47:22 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> It's preferred to indent multi-line argument lists on the column where argument list starts.
>
> assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)",
>        src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name());

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From darcy at openjdk.java.net  Fri May 13 21:25:26 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 13 May 2022 21:25:26 GMT
Subject: RFR: JDK-8286760: Update citation of "Effective Java" second edition
 to third edition
Message-ID: <hP5Mac_L0h-A5SHEW3vOYSPTdagKQb681icbJ1DMWMo=.a8fa9a87-f30a-40c3-969b-7ac55267c249@github.com>

Update reference to the latest "Effective Java" version and switch to cite tags.

-------------

Commit messages:
 - JDK-8286760: Update citation of "Effective Java" second edition to third edition

Changes: https://git.openjdk.java.net/jdk/pull/8707/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8707&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286760
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8707.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8707/head:pull/8707

PR: https://git.openjdk.java.net/jdk/pull/8707

From mcimadamore at openjdk.java.net  Fri May 13 21:34:20 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 May 2022 21:34:20 GMT
Subject: RFR: 8286756: Cleanup foreign API benchmarks
Message-ID: <548L9IsOJxCm2fzP-G5IzPkTLsu9UXHM8MW1_Ereb-M=.af48c268-0144-4200-ae98-7fad29f23a3f@github.com>

This simple patch regularizes some of the foreign API benchmarks. Some of the changes are:

* use of capital names for var handle and layout constants
* move shared layout and var handle constants in a new superclass, `JavaLayouts`
* regularize aligned vs. unaligned benchmarks, especially in `LoopOverNonConstantHeap`. Since the API now aligns layouts by default, where the benchmark name doesn't say anything we assume aligned layout; for benchmarks that test specifically the use of unaligned layouts, we use the `_unaligned` prefix.

-------------

Commit messages:
 - Fix whitespaces
 - Initial push

Changes: https://git.openjdk.java.net/jdk/pull/8705/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8705&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286756
  Stats: 204 lines in 13 files changed: 54 ins; 69 del; 81 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8705.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8705/head:pull/8705

PR: https://git.openjdk.java.net/jdk/pull/8705

From bpb at openjdk.java.net  Fri May 13 21:45:43 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 13 May 2022 21:45:43 GMT
Subject: RFR: JDK-8286760: Update citation of "Effective Java" second
 edition to third edition
In-Reply-To: <hP5Mac_L0h-A5SHEW3vOYSPTdagKQb681icbJ1DMWMo=.a8fa9a87-f30a-40c3-969b-7ac55267c249@github.com>
References: <hP5Mac_L0h-A5SHEW3vOYSPTdagKQb681icbJ1DMWMo=.a8fa9a87-f30a-40c3-969b-7ac55267c249@github.com>
Message-ID: <HSsk7k348jFQzjfU2-bvMAvsFXYHezw0oPVezYIUTN0=.e24774a9-b81d-4780-8660-ee6c71bcc9f0@github.com>

On Fri, 13 May 2022 21:17:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update reference to the latest "Effective Java" version and switch to cite tags.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8707

From prappo at openjdk.java.net  Fri May 13 21:57:46 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 13 May 2022 21:57:46 GMT
Subject: RFR: JDK-8286760: Update citation of "Effective Java" second
 edition to third edition
In-Reply-To: <hP5Mac_L0h-A5SHEW3vOYSPTdagKQb681icbJ1DMWMo=.a8fa9a87-f30a-40c3-969b-7ac55267c249@github.com>
References: <hP5Mac_L0h-A5SHEW3vOYSPTdagKQb681icbJ1DMWMo=.a8fa9a87-f30a-40c3-969b-7ac55267c249@github.com>
Message-ID: <gBTUxLFRf51FZVrATwLuW-9JNSXnm6_VuHemgF8DCFg=.a0ea14d5-a06b-49c1-8dbd-eb4fc19da616@github.com>

On Fri, 13 May 2022 21:17:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update reference to the latest "Effective Java" version and switch to cite tags.

Looks good!

1. Had to educate myself on the [cite element](https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-cite-element). The HTML spec can amuse at times:
    
    A person's name is not the title of a work ? even if people call that person a piece of work ? and the element must therefore not be used to mark up people's names.

2. Indeed, items 69 and 81 are both "Prefer concurrency utilities to wait and notify".

-------------

Marked as reviewed by prappo (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8707

From joehw at openjdk.java.net  Fri May 13 22:14:50 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 13 May 2022 22:14:50 GMT
Subject: RFR: 8286399: Address possibly lossy conversions in JDK Build
 Tools
In-Reply-To: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com>
References: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com>
Message-ID: <XKhPV7zEEwyAfKpQvlE6WHaLn1dQijQR1LZlvelwOzU=.80eba5c8-79a3-4894-948e-08c745fcb802@github.com>

On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch.

make/jdk/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java line 1278:

> 1276:             state[numCategories] |= (short) END_STATE_FLAG;
> 1277:             if (sawEarlyBreak) {
> 1278:                 state[numCategories] |= LOOKAHEAD_STATE_FLAG;

Does this need a cast as well? and also other cases, e.g. line 1019: state[numCategories] = DONT_LOOP_FLAG;?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8706

From naoto at openjdk.java.net  Fri May 13 22:33:42 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 13 May 2022 22:33:42 GMT
Subject: RFR: 8286399: Address possibly lossy conversions in JDK Build
 Tools
In-Reply-To: <XKhPV7zEEwyAfKpQvlE6WHaLn1dQijQR1LZlvelwOzU=.80eba5c8-79a3-4894-948e-08c745fcb802@github.com>
References: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com>
 <XKhPV7zEEwyAfKpQvlE6WHaLn1dQijQR1LZlvelwOzU=.80eba5c8-79a3-4894-948e-08c745fcb802@github.com>
Message-ID: <nxv6qpVe_0h9y42uiXWrYKuItsAbuKua5evjbAFr13o=.329abd91-66b5-40ce-92e9-74664acda9c1@github.com>

On Fri, 13 May 2022 22:11:17 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch.
>
> make/jdk/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java line 1278:
> 
>> 1276:             state[numCategories] |= (short) END_STATE_FLAG;
>> 1277:             if (sawEarlyBreak) {
>> 1278:                 state[numCategories] |= LOOKAHEAD_STATE_FLAG;
> 
> Does this need a cast as well? and also other cases, e.g. line 1019: state[numCategories] = DONT_LOOP_FLAG;?

No, it doesn't. `LOOKAHEAD_STATE_FLAG` is defined as `0x2000` which is within the range of `short`. OTOH, `END_STATE_FLAG` is `0x8000` thus a lossy conversion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8706

From kbarrett at openjdk.java.net  Fri May 13 23:26:31 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 13 May 2022 23:26:31 GMT
Subject: RFR: 8286705: GCC 12 reports use-after-free potential bugs
In-Reply-To: <XWaHVowJNTNpM09udI33X6K22npPRvmIBXjSPoP_h_k=.7204a69a-7d80-47ee-99b1-83371278339a@github.com>
References: <XWaHVowJNTNpM09udI33X6K22npPRvmIBXjSPoP_h_k=.7204a69a-7d80-47ee-99b1-83371278339a@github.com>
Message-ID: <BTuWR9JJL88o_RruWvG49my1TCTSo0dypwbE140_BRo=.61f99ff3-06e2-424e-86c2-cd9507e6a7c6@github.com>

On Fri, 13 May 2022 09:14:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> GCC 12 reports use-after-free potential bugs in below:
> 
> 
> In function 'find_positions',
>     inlined from 'find_file' at /home/ysuenaga/github-forked/jdk/src/java.base/share/native/libjli/parse_manifest.c:364:9:

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8696

From joehw at openjdk.java.net  Fri May 13 23:45:37 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 13 May 2022 23:45:37 GMT
Subject: RFR: 8286399: Address possibly lossy conversions in JDK Build
 Tools
In-Reply-To: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com>
References: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com>
Message-ID: <hFApRBVyvblZKYrREQjSvuDn_VfDkB56TvAX_UwThfg=.074049c8-b46c-44d0-a25c-889ce8d04ba4@github.com>

On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8706

From duke at openjdk.java.net  Sat May 14 00:36:06 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Sat, 14 May 2022 00:36:06 GMT
Subject: RFR: JDK-8281001 Examine the behavior of Class::forName if the caller
 is null
Message-ID: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>

The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.

-------------

Commit messages:
 - Merge branch 'master' into JDK-8281001
 - JDK-8281001 Examine the behavior of Class::forName if the caller is null

Changes: https://git.openjdk.java.net/jdk/pull/8711/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8711&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281001
  Stats: 19 lines in 3 files changed: 18 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

PR: https://git.openjdk.java.net/jdk/pull/8711

From darcy at openjdk.java.net  Sat May 14 00:43:47 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 14 May 2022 00:43:47 GMT
Subject: RFR: JDK-8281001 Examine the behavior of Class::forName if the
 caller is null
In-Reply-To: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
Message-ID: <rNAqjCsLVnZuo8UEDcn_hXP1iR7_LEVt16l8XWykbfg=.3f5fc1f9-b5e6-4926-9065-39f3abbf56d1@github.com>

On Sat, 14 May 2022 00:30:00 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.

@tprinzing , please file a CSR for this discuss so the behavioral changes can be reviewed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8711

From jpai at openjdk.java.net  Sat May 14 03:25:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 14 May 2022 03:25:40 GMT
Subject: RFR: 8286559: Re-examine synchronization of mark and reset methods
 on InflaterInputStream [v2]
In-Reply-To: <vIUGW95vCL2b2qYV8amMIKMMyvmRc6XJoEWAN0N1crM=.7bfe3433-10d2-4704-8867-1ab31cd42691@github.com>
References: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
 <vIUGW95vCL2b2qYV8amMIKMMyvmRc6XJoEWAN0N1crM=.7bfe3433-10d2-4704-8867-1ab31cd42691@github.com>
Message-ID: <3XuPmmlt9gNkMG5MVJdry5msBFwx-1xdq8Coj0iDA6o=.84a88e55-264f-4d15-8ddb-e867e5b983cd@github.com>

On Fri, 13 May 2022 07:14:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change that addresses https://bugs.openjdk.java.net/browse/JDK-8286559? 
>> 
>> The commit here removes the `synchronized` on `mark` and `reset` methods of `InflaterInputStream`. The `mark` method is a no-op method and the `reset` method only always throws a `IOException`. So `synchronized` isn't adding any value here. 
>> 
>> Additionally, the commit does a minor change to the javadoc of these methods to use `@implNote` to describe what the implementation does. Please let me know if the `@implNote` is unnecessary, in which case, I'll revert that part.
>> 
>> This change is similar to what was recently done for `FilterInputStream` https://github.com/openjdk/jdk/pull/8309 and `PushbackInputStream` https://github.com/openjdk/jdk/pull/8433
>> 
>> tier1, tier2 and tier3 tests were run and no related failures were noticed.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Incorporate review comment made on CSR by Joe - Change @implNote to @implSpec

Thank you everyone for the reviews here and on the CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8649

From jpai at openjdk.java.net  Sat May 14 03:25:41 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 14 May 2022 03:25:41 GMT
Subject: Integrated: 8286559: Re-examine synchronization of mark and reset
 methods on InflaterInputStream
In-Reply-To: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
References: <iE8Czq4ei3m-0iD6YR8DIBzFgv3CxKWqmTMugAkyw6g=.0db8fb5c-31ad-466e-8b20-99aeab46417e@github.com>
Message-ID: <2RLofgz05syv56oROrfIYSiXTSlYdbkLhWUbXt502tQ=.87f8feed-4379-4270-ac7b-b4129e77351a@github.com>

On Wed, 11 May 2022 09:00:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change that addresses https://bugs.openjdk.java.net/browse/JDK-8286559? 
> 
> The commit here removes the `synchronized` on `mark` and `reset` methods of `InflaterInputStream`. The `mark` method is a no-op method and the `reset` method only always throws a `IOException`. So `synchronized` isn't adding any value here. 
> 
> Additionally, the commit does a minor change to the javadoc of these methods to use `@implNote` to describe what the implementation does. Please let me know if the `@implNote` is unnecessary, in which case, I'll revert that part.
> 
> This change is similar to what was recently done for `FilterInputStream` https://github.com/openjdk/jdk/pull/8309 and `PushbackInputStream` https://github.com/openjdk/jdk/pull/8433
> 
> tier1, tier2 and tier3 tests were run and no related failures were noticed.

This pull request has now been integrated.

Changeset: e4378ab2
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e4378ab28d46fb1270a2d6b3388838ce790a9fb5
Stats:     6 lines in 1 file changed: 2 ins; 0 del; 4 mod

8286559: Re-examine synchronization of mark and reset methods on InflaterInputStream

Reviewed-by: lancea, alanb, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8649

From jiefu at openjdk.java.net  Sat May 14 10:17:39 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 14 May 2022 10:17:39 GMT
Subject: RFR: 8286681: ShenandoahControlThread::request_gc misses the case
 of GCCause::_codecache_GC_threshold [v2]
In-Reply-To: <oZItDX1dvCDJnf1J2750lTdXHAPtPRS7_LUpTPubAsk=.790840bc-d347-40e1-87ed-2f8b8025ff60@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
 <oZItDX1dvCDJnf1J2750lTdXHAPtPRS7_LUpTPubAsk=.790840bc-d347-40e1-87ed-2f8b8025ff60@github.com>
Message-ID: <qAYsYTds6x8Cz1Yp2xoBevJiBpuiMRWDVnFnlHgBdv8=.6497fa79-d4f6-433c-9ca0-718daf012005@github.com>

On Fri, 13 May 2022 12:27:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> LGTM

Thanks @zhengyu123 for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8691

From jiefu at openjdk.java.net  Sat May 14 10:17:39 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 14 May 2022 10:17:39 GMT
Subject: Integrated: 8286681: ShenandoahControlThread::request_gc misses the
 case of GCCause::_codecache_GC_threshold
In-Reply-To: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
References: <T6PElbKBgFB_PA8rFLaasqptZDrUtJkZb59xUHmiWAM=.859e595e-0238-4f5e-bb17-3577ceaad790@github.com>
Message-ID: <7FhFBw0mS9iLpQbgQGHhwo8EItF2WysYc7mivFnM06k=.191dc815-f675-4840-a4fb-1cb94a36d0b4@github.com>

On Fri, 13 May 2022 02:43:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Some tests fail with Shenandoah GC after JDK-8282191.
> The reason is that the assert in `ShenandoahControlThread::request_gc` misses the case of `GCCause::_codecache_GC_threshold`.
> It would be better to fix it.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 9eb15c9b
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9eb15c9b100b87e332c572bbc24a818e1cceb180
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8286681: ShenandoahControlThread::request_gc misses the case of GCCause::_codecache_GC_threshold

Reviewed-by: zgu

-------------

PR: https://git.openjdk.java.net/jdk/pull/8691

From clanger at openjdk.java.net  Sat May 14 11:00:52 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sat, 14 May 2022 11:00:52 GMT
Subject: RFR: 8286594: (zipfs) Mention paths with dot elements in
 ZipException and cleanups
In-Reply-To: <-CY8VrgET0umvXMyeB9s7y_b9qsON3_mTD5IDtHiuyU=.aeeb6720-a674-42c5-bd6a-be864d9e2021@github.com>
References: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com>
 <-CY8VrgET0umvXMyeB9s7y_b9qsON3_mTD5IDtHiuyU=.aeeb6720-a674-42c5-bd6a-be864d9e2021@github.com>
Message-ID: <PRJDkOUIy2OJilu41xR2LiC-cdLn0xjehN-T7cYfUDo=.17a1df16-3748-41fc-a033-b93d21293edb@github.com>

On Wed, 11 May 2022 19:20:15 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements.
>> 
>> It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode::nameAsString to return the node name as a String.
>
> Looks good Christoph.  Thank you for separating this out from the other PR

Thanks @LanceAndersen for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8655

From clanger at openjdk.java.net  Sat May 14 11:00:54 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sat, 14 May 2022 11:00:54 GMT
Subject: Integrated: 8286594: (zipfs) Mention paths with dot elements in
 ZipException and cleanups
In-Reply-To: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com>
References: <9fuSmMdii8pkUwW1_nJWlBQxV8P7XPAmf9kyA1OlXmM=.e2d0eb03-0027-4ade-bbed-cd3f5ef21170@github.com>
Message-ID: <IK9ffaEEXxOz8_0ORwb15BAVj5uLGtQEBcaD8ejw7nE=.9f930c89-1cc3-4295-81d1-b3c082fd7621@github.com>

On Wed, 11 May 2022 15:32:38 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> This augments the ZipException upon rejecting a Zip File containing entry names with "." or ".." elements.
> 
> It furthermore tries to clean up & compact the logic for detecting "." and ".." and it adds a method IndexNode::nameAsString to return the node name as a String.

This pull request has now been integrated.

Changeset: 80cf9f34
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/80cf9f3464c599fb7860432bf4ed506a3b298d8e
Stats:     73 lines in 1 file changed: 31 ins; 38 del; 4 mod

8286594: (zipfs) Mention paths with dot elements in ZipException and cleanups

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8655

From ysuenaga at openjdk.java.net  Sun May 15 01:36:50 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 15 May 2022 01:36:50 GMT
Subject: Integrated: 8286705: GCC 12 reports use-after-free potential bugs
In-Reply-To: <XWaHVowJNTNpM09udI33X6K22npPRvmIBXjSPoP_h_k=.7204a69a-7d80-47ee-99b1-83371278339a@github.com>
References: <XWaHVowJNTNpM09udI33X6K22npPRvmIBXjSPoP_h_k=.7204a69a-7d80-47ee-99b1-83371278339a@github.com>
Message-ID: <oHIDh_lxskM6JNmfA-cQutB7lkKFnnkvmzgc40kRIn0=.25424fb3-e20e-4c76-8c88-e4c61bdbe0a0@github.com>

On Fri, 13 May 2022 09:14:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> GCC 12 reports use-after-free potential bugs in below:
> 
> 
> In function 'find_positions',
>     inlined from 'find_file' at /home/ysuenaga/github-forked/jdk/src/java.base/share/native/libjli/parse_manifest.c:364:9:

This pull request has now been integrated.

Changeset: 0e4bece5
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0e4bece5b5143b8505496ea7430bbfa11e151aff
Stats:     8 lines in 2 files changed: 4 ins; 1 del; 3 mod

8286705: GCC 12 reports use-after-free potential bugs

Reviewed-by: kbarrett

-------------

PR: https://git.openjdk.java.net/jdk/pull/8696

From aturbanov at openjdk.java.net  Sun May 15 10:31:20 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sun, 15 May 2022 10:31:20 GMT
Subject: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX
 [v2]
In-Reply-To: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
References: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
Message-ID: <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com>

> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
> Compared via JMH benchmark: 150ns -> 125ns/op
> <details>
> <summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary>
> 
> 
> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class TimeUnitBench {
> 
>     static final int SIZE = TimeUnit.values().length * 10;
> 
>     @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
>     int bias;
> 
>     TimeUnit[] mod;
> 
>     @Setup
>     public void setup() {
>         mod = new TimeUnit[SIZE];
> 
>         TimeUnit[] vals = TimeUnit.values();
>         for (int c = 0; c < SIZE; c++) {
>             if (bias == -1) {
>                 // megamorphic
>                 mod[c] = vals[c % vals.length];
>             } else {
>                 mod[c] = vals[bias];
>             }
>         }
> 
>         Random r = new Random();
>         for (int c = 0; c < 10000; c++) {
>             int i = r.nextInt();
>             for (int o = 0; o < vals.length; o++) {
>                 if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o]))
>                     throw new IllegalStateException("switch " + o);
>             }
>         }
>     }
> 
>     @Benchmark
>     public void const_convert(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_convert(tu));
>         }
>     }
> 
>     @Benchmark
>     public void value_convert(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_convert(tu, 1L));
>         }
>     }
> 
>     @Benchmark
>     public void const_toNanos(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_toNanos(tu));
>         }
>     }
> 
>     @Benchmark
>     public void value_toNanos(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_toNanos(tu, 1L));
>         }
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_toNanos(TimeUnit tu) {
>         return tu.toNanos(1L);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_toNanos(TimeUnit tu, long value) {
>         return tu.toNanos(value);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_convert(TimeUnit tu) {
>         return TimeUnit.NANOSECONDS.convert(1L, tu);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_convert(TimeUnit tu, long value) {
>         return TimeUnit.NANOSECONDS.convert(value, tu);
>     }
> }
> 
> Results:
> 
> Benchmark                    (bias)  Mode  Cnt    Score    Error  Units
> TimeUnitBench.const_convert       0  avgt    5  151,856 ? 28,595  ns/op
> TimeUnitBench.const_convert       1  avgt    5  150,720 ? 23,863  ns/op
> TimeUnitBench.const_convert       2  avgt    5  151,432 ? 23,184  ns/op
> TimeUnitBench.const_convert       3  avgt    5  150,959 ? 24,726  ns/op
> TimeUnitBench.const_convert       4  avgt    5  150,966 ? 25,280  ns/op
> TimeUnitBench.const_convert       5  avgt    5  150,976 ? 25,542  ns/op
> TimeUnitBench.const_convert       6  avgt    5  151,118 ? 25,254  ns/op
> TimeUnitBench.const_convert      -1  avgt    5  152,673 ? 29,861  ns/op
> TimeUnitBench.const_toNanos       0  avgt    5  121,296 ? 25,236  ns/op
> TimeUnitBench.const_toNanos       1  avgt    5  121,707 ? 25,364  ns/op
> TimeUnitBench.const_toNanos       2  avgt    5  121,736 ? 25,726  ns/op
> TimeUnitBench.const_toNanos       3  avgt    5  121,822 ? 25,491  ns/op
> TimeUnitBench.const_toNanos       4  avgt    5  121,867 ? 26,090  ns/op
> TimeUnitBench.const_toNanos       5  avgt    5  121,927 ? 25,611  ns/op
> TimeUnitBench.const_toNanos       6  avgt    5  121,821 ? 25,843  ns/op
> TimeUnitBench.const_toNanos      -1  avgt    5  121,923 ? 25,206  ns/op
> TimeUnitBench.value_convert       0  avgt    5  150,525 ? 25,439  ns/op
> TimeUnitBench.value_convert       1  avgt    5  151,098 ? 24,024  ns/op
> TimeUnitBench.value_convert       2  avgt    5  151,259 ? 25,381  ns/op
> TimeUnitBench.value_convert       3  avgt    5  151,030 ? 25,548  ns/op
> TimeUnitBench.value_convert       4  avgt    5  151,290 ? 25,998  ns/op
> TimeUnitBench.value_convert       5  avgt    5  151,006 ? 25,448  ns/op
> TimeUnitBench.value_convert       6  avgt    5  150,945 ? 25,314  ns/op
> TimeUnitBench.value_convert      -1  avgt    5  151,186 ? 25,814  ns/op
> TimeUnitBench.value_toNanos       0  avgt    5  121,556 ? 25,745  ns/op
> TimeUnitBench.value_toNanos       1  avgt    5  123,410 ? 22,323  ns/op
> TimeUnitBench.value_toNanos       2  avgt    5  125,452 ? 26,575  ns/op
> TimeUnitBench.value_toNanos       3  avgt    5  125,297 ? 26,204  ns/op
> TimeUnitBench.value_toNanos       4  avgt    5  125,357 ? 26,085  ns/op
> TimeUnitBench.value_toNanos       5  avgt    5  125,165 ? 26,185  ns/op
> TimeUnitBench.value_toNanos       6  avgt    5  125,536 ? 25,487  ns/op
> TimeUnitBench.value_toNanos      -1  avgt    5  125,460 ? 25,063  ns/op
> 
> 
> </details>

Andrey Turbanov 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 remote-tracking branch 'origin/master' into Use_direct_TimeUnit.toSome_instead_of_TimeUnit.convert
   
   # Conflicts:
   #	src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java
   #	src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java
 - [PATCH] Simplify TimeUnit.convert calls to TimeUnit.toSomething instead

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8376/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8376&range=01
  Stats: 24 lines in 4 files changed: 2 ins; 0 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8376/head:pull/8376

PR: https://git.openjdk.java.net/jdk/pull/8376

From lbourges at openjdk.java.net  Sun May 15 11:27:53 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 15 May 2022 11:27:53 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <Qe0gyxT2wBb49m8qhDLGfzW_4zRLWCIIKuyU4Gl1aTU=.faebadab-9822-48ec-9f31-8b499bf768dc@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
 <Qe0gyxT2wBb49m8qhDLGfzW_4zRLWCIIKuyU4Gl1aTU=.faebadab-9822-48ec-9f31-8b499bf768dc@github.com>
Message-ID: <1QwEkaWtFByK-xudkVFFXBV-nonAp7DNC6FoA1ldc2s=.de09d927-f1a7-4009-bd89-2d81c5bd7405@github.com>

On Fri, 13 May 2022 17:48:50 GMT, Piotr Tarsa <duke at openjdk.java.net> wrote:

> allocating extra buffers and catching OOME when sorting primitives is rather unsatisfactory. you're not giving a reliable option for sorting under low memory conditions. IMO at least the single-threaded primitives (ints, longs, floats, etc all non-objects) sorting should be frugal when it comes to memory usage.
> 
> just my 2 cents.

DPQS uses several sorting algorithms, merge sort & new radix sort need an extra buffer in contrary to isort, mixed isort, single and dual pivot quick sort.
In this PR an upper limit on the heap usage is in use min(max heap / 16, 128mb) to reduce the memory footprint. 
Anyway catching OOME now permits DPQS to use in-place but slower algorithms if the extra buffer can not be allocated.
Possibly the upper limit could be made configurable using system properties if it is really critical.
To sum up, low allocations are now under control in this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From lbourges at openjdk.java.net  Sun May 15 12:23:43 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Sun, 15 May 2022 12:23:43 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <OkvwXwjFGRY3o0xBR3Q8BagsqHfQF-WRGVzQGKSCu2o=.d9194f44-22ee-4e75-b897-01ff99465c75@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

I checked the latest code: line 128:

Max length of additional buffer, limited by max_heap / 64 or 256mb elements (2gb max).
    
    private static final int MAX_BUFFER_LENGTH =
            (int) Math.min(Runtime.getRuntime().maxMemory() >> 6, 256L << 20);

So the current upper limit concerns the max length = max_heap_bytes / 64 (max heap/8) or 2gb (if heap is huge).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From duke at openjdk.java.net  Sun May 15 14:22:55 2022
From: duke at openjdk.java.net (Piotr Tarsa)
Date: Sun, 15 May 2022 14:22:55 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <0d9ibGxiPSy-z1StNpU81FyxWM6bBNrAAj1x-AZlAtE=.f7a6271b-4339-4c1c-9e48-24b96d2813f9@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

i think it would make much more sense to have the extra buffer size limit in bytes, not in elements. for single-threaded sorting the limit should be low, e.g. 1/64 of the heap, not 1/8 (in case of sorting e.g. longs as each long is 8 byte long). multi-threaded sorting could be more aggressive when it comes to resource usage as it's less likely to be used in resource constrained environment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From darcy at openjdk.java.net  Sun May 15 18:44:11 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sun, 15 May 2022 18:44:11 GMT
Subject: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses
Message-ID: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>

Make the javadoc in the InputStream and OutputStream subclasses in core libs DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in client libs will be done another a separate bug.) When the time comes, will do any necessary merging for the changes in[JDK-8286200.

Please also review the CSR to cover the introduction of implspec and implNote tags: https://bugs.openjdk.java.net/browse/JDK-8286784

-------------

Commit messages:
 - JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses

Changes: https://git.openjdk.java.net/jdk/pull/8717/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8717&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286783
  Stats: 190 lines in 13 files changed: 49 ins; 45 del; 96 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8717.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8717/head:pull/8717

PR: https://git.openjdk.java.net/jdk/pull/8717

From alanb at openjdk.java.net  Sun May 15 19:28:46 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 15 May 2022 19:28:46 GMT
Subject: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses
In-Reply-To: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
References: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
Message-ID: <oN2qbmMFeLEesa2a_sZaH9p2uUCQ-yfkwsqgmuBeLCI=.3c16868e-3946-4f59-b663-7db147545105@github.com>

On Sun, 15 May 2022 18:36:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make the javadoc in the InputStream and OutputStream subclasses in core libs DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in client libs will be done another a separate bug.) When the time comes, will do any necessary merging for the changes in[JDK-8286200.
> 
> Please also review the CSR to cover the introduction of implspec and implNote tags: https://bugs.openjdk.java.net/browse/JDK-8286784

Picking FileInputStream at random, I wonder if the `@inheritDoc` on transferTo is needed. Also, I think you've attempted to add `@Override` to all overridden methods but some may have been missed (e.g. readAllBytes and readNBytes).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8717

From prappo at openjdk.java.net  Sun May 15 21:20:42 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sun, 15 May 2022 21:20:42 GMT
Subject: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses
In-Reply-To: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
References: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
Message-ID: <luHclXr6lXAgEGyOtTlIABc2mQmms2okpJY9EAcilIg=.d6f32599-a238-489a-bcc4-a64955767210@github.com>

On Sun, 15 May 2022 18:36:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make the javadoc in the InputStream and OutputStream subclasses in core libs DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in client libs will be done another a separate bug.) When the time comes, will do any necessary merging for the changes in[JDK-8286200.
> 
> Please also review the CSR to cover the introduction of implspec and implNote tags: https://bugs.openjdk.java.net/browse/JDK-8286784

1. One the one hand, it's not clear to me what criterion was used for adding `@Override` annotations. On the other hand, the more `@Override` annotations a codebase has, the better.
2. Have you compared the resulting documentation before and after the change? Aside from added `@implSpec` and `@implNote`, were there anything anything different?
3. I wonder if it makes sense to also reduce the size of the doc comments by changing explicit documentation inheritance for the `@param` and `@return` tags to implicit one, i.e. removing the tags on the overrider's side.

src/java.base/share/classes/java/io/SequenceInputStream.java line 217:

> 215:      * before the {@code close} method returns.
> 216:      *
> 217:      * @throws IOException {@inheritDoc}

Unexpected re-indentation; other similar cases do not have it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8717

From dholmes at openjdk.java.net  Mon May 16 01:26:43 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 16 May 2022 01:26:43 GMT
Subject: RFR: 8286368: Cleanup problem lists after loom integration [v2]
In-Reply-To: <Stq8HlCgHVfFJo_AWSLCBbPjK0BsRHMdC7OwyQOC4WI=.18632196-3b50-41de-8412-a7fd7e508e27@github.com>
References: <FGFlG77wBJ_9oPlKFrldqBG_9ixAOGZW6ZHAuEVxkmk=.19ac9767-45f6-4441-89da-66663b9c6e53@github.com>
 <Stq8HlCgHVfFJo_AWSLCBbPjK0BsRHMdC7OwyQOC4WI=.18632196-3b50-41de-8412-a7fd7e508e27@github.com>
Message-ID: <lDvkAhGUbyzVBF0IWzawKTWGfoGUvyNdQnjcxusbdQg=.297d1b47-59e7-42d4-9dbe-124fd82eb20a@github.com>

On Tue, 10 May 2022 19:16:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> 8286368: Cleanup problem lists after loom integration
>
> Leonid Mesnik 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
>  - 8286368: Cleanup problem lists after loom integration

test/hotspot/jtreg/ProblemList-Xcomp.txt line 38:

> 36: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64
> 37: 
> 38: compiler/c2/irTests/TestSkeletonPredicates.java 8286361 generic-all

@lmesnik This line should not have been removed!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8604

From duke at openjdk.java.net  Mon May 16 02:16:51 2022
From: duke at openjdk.java.net (xpbob)
Date: Mon, 16 May 2022 02:16:51 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness
In-Reply-To: <yLrox8Oafj87mWSj8y65ngi17I-exRllezE2o1f0dv0=.36f1ba12-2bbe-47f9-8a8d-bf96702ee277@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <yLrox8Oafj87mWSj8y65ngi17I-exRllezE2o1f0dv0=.36f1ba12-2bbe-47f9-8a8d-bf96702ee277@github.com>
Message-ID: <o2nhG-kRG4m8oIghPNlVyeE2-BAJEqWyqJat63l8f68=.1c42cd23-5f4d-46b8-8c5e-5acfcfe8a633@github.com>

On Wed, 20 Apr 2022 06:53:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> I changed the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8284900) summary to "CgroupV1 detection code should consider memory.swappiness"

@iklam , are you also fine with the latest change? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From lmesnik at openjdk.java.net  Mon May 16 02:28:47 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 16 May 2022 02:28:47 GMT
Subject: RFR: 8286368: Cleanup problem lists after loom integration [v2]
In-Reply-To: <lDvkAhGUbyzVBF0IWzawKTWGfoGUvyNdQnjcxusbdQg=.297d1b47-59e7-42d4-9dbe-124fd82eb20a@github.com>
References: <FGFlG77wBJ_9oPlKFrldqBG_9ixAOGZW6ZHAuEVxkmk=.19ac9767-45f6-4441-89da-66663b9c6e53@github.com>
 <Stq8HlCgHVfFJo_AWSLCBbPjK0BsRHMdC7OwyQOC4WI=.18632196-3b50-41de-8412-a7fd7e508e27@github.com>
 <lDvkAhGUbyzVBF0IWzawKTWGfoGUvyNdQnjcxusbdQg=.297d1b47-59e7-42d4-9dbe-124fd82eb20a@github.com>
Message-ID: <GkoIg6W08S5w0EXqYhsDciP_0w2j__pioWlj6pntks8=.961bd69d-e871-4821-9ad5-c14c6e02a0a6@github.com>

On Mon, 16 May 2022 01:23:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik 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
>>  - 8286368: Cleanup problem lists after loom integration
>
> test/hotspot/jtreg/ProblemList-Xcomp.txt line 38:
> 
>> 36: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64
>> 37: 
>> 38: compiler/c2/irTests/TestSkeletonPredicates.java 8286361 generic-all
> 
> @lmesnik This line should not have been removed!

It might be a merge problem. My PR was submitted before 8286442. I remereged changes, however my merge commit also doesn't have removal of this line:
https://github.com/openjdk/jdk/pull/8604/commits/8255e760ff1a2ff616f00f559de29e66d7036b39

So I am really confused and can't understand how I managed to introduce this problem.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8604

From dholmes at openjdk.java.net  Mon May 16 02:41:48 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 16 May 2022 02:41:48 GMT
Subject: RFR: 8286368: Cleanup problem lists after loom integration [v2]
In-Reply-To: <GkoIg6W08S5w0EXqYhsDciP_0w2j__pioWlj6pntks8=.961bd69d-e871-4821-9ad5-c14c6e02a0a6@github.com>
References: <FGFlG77wBJ_9oPlKFrldqBG_9ixAOGZW6ZHAuEVxkmk=.19ac9767-45f6-4441-89da-66663b9c6e53@github.com>
 <Stq8HlCgHVfFJo_AWSLCBbPjK0BsRHMdC7OwyQOC4WI=.18632196-3b50-41de-8412-a7fd7e508e27@github.com>
 <lDvkAhGUbyzVBF0IWzawKTWGfoGUvyNdQnjcxusbdQg=.297d1b47-59e7-42d4-9dbe-124fd82eb20a@github.com>
 <GkoIg6W08S5w0EXqYhsDciP_0w2j__pioWlj6pntks8=.961bd69d-e871-4821-9ad5-c14c6e02a0a6@github.com>
Message-ID: <c8WFC0qcf8ATFZCXhoQYkpVOeOdbFhrjE_qJLAnSbak=.6e38c84d-2289-4122-a658-c28e98d4c6a8@github.com>

On Mon, 16 May 2022 02:25:26 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/hotspot/jtreg/ProblemList-Xcomp.txt line 38:
>> 
>>> 36: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64
>>> 37: 
>>> 38: compiler/c2/irTests/TestSkeletonPredicates.java 8286361 generic-all
>> 
>> @lmesnik This line should not have been removed!
>
> It might be a merge problem. My PR was submitted before 8286442. I remereged changes, however my merge commit also doesn't have removal of this line:
> https://github.com/openjdk/jdk/pull/8604/commits/8255e760ff1a2ff616f00f559de29e66d7036b39
> 
> So I am really confused and can't understand how I managed to introduce this problem.

That is really bizarre. No individual commit shows the line being deleted, yet in the final commit it is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8604

From iklam at openjdk.java.net  Mon May 16 03:55:42 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 16 May 2022 03:55:42 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v18]
In-Reply-To: <8rNf17Q6js-lYaRIA31S6ft-GB2fYNfpEJvNja2Blc4=.d803b76c-c43f-4569-a8aa-16fc496bdad6@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <8rNf17Q6js-lYaRIA31S6ft-GB2fYNfpEJvNja2Blc4=.d803b76c-c43f-4569-a8aa-16fc496bdad6@github.com>
Message-ID: <E5csb1RGYeshZiBA61_YzzwaS0Dx5MkC3E79JpKroGA=.c7db241d-1fe7-4ab2-9be1-59628a9c0ea7@github.com>

On Thu, 12 May 2022 13:46:11 GMT, xpbob <duke at openjdk.java.net> wrote:

>> set memory.swappiness to 0,swap space will not be used 
>> determine the value of memory.swappiness
>> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
>> 
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 100.00M
>>     Maximum Processes Limit: 4194305 
>> 
>> =>
>> 
>>     Memory Limit: 50.00M
>>     Memory Soft Limit: Unlimited
>>     Memory & Swap Limit: 50.00M
>>     Maximum Processes Limit: 4194305
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename method

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Mon May 16 04:53:51 2022
From: duke at openjdk.java.net (Shruthi)
Date: Mon, 16 May 2022 04:53:51 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <ZbzIYm_ACXidlRDyVYZ8H73rZmx11NBW9zntTUW-PpM=.e0cab1f9-9b45-4e41-a53b-56fd7e14d8f9@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
 <ZbzIYm_ACXidlRDyVYZ8H73rZmx11NBW9zntTUW-PpM=.e0cab1f9-9b45-4e41-a53b-56fd7e14d8f9@github.com>
Message-ID: <kr6IVjQfQh1DXdaCsegmFJTI4m5wMPwsryp7iWuosI8=.5ac950ab-064a-4c24-8754-252496194d23@github.com>

On Fri, 13 May 2022 18:51:47 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Shruthi 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:
>> 
>>   Modify copyright year
>
> Did you mean the failure (Pre-submit tests - Linux x86 - Test (tier1) ) above?  That's not related to your change.

@JoeWang-Java Yes. 
Shall I comment as **integrate** then?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From jlahoda at openjdk.java.net  Mon May 16 05:36:41 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 16 May 2022 05:36:41 GMT
Subject: RFR: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview) [v13]
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <aR054lcdcbQUcI8Q_n4045NjZnV4JvwUmjFYXaqws9s=.8b1beed0-1cc7-4c3f-8163-4d64380f7b89@github.com>

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing test - restoring accidentally removed condition.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8182/files
  - new: https://git.openjdk.java.net/jdk/pull/8182/files/e903084a..22991958

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8182&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8182/head:pull/8182

PR: https://git.openjdk.java.net/jdk/pull/8182

From duke at openjdk.java.net  Mon May 16 06:06:01 2022
From: duke at openjdk.java.net (xpbob)
Date: Mon, 16 May 2022 06:06:01 GMT
Subject: RFR: 8284950: CgroupV1 detection code should consider
 memory.swappiness [v18]
In-Reply-To: <sq25sF5YHOrgQiTTbluMS67Krdam3wz1YGfXaaC-Ne0=.b38fa7a5-7f11-4258-ab77-7828246eeef7@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
 <8rNf17Q6js-lYaRIA31S6ft-GB2fYNfpEJvNja2Blc4=.d803b76c-c43f-4569-a8aa-16fc496bdad6@github.com>
 <sq25sF5YHOrgQiTTbluMS67Krdam3wz1YGfXaaC-Ne0=.b38fa7a5-7f11-4258-ab77-7828246eeef7@github.com>
Message-ID: <8EJ7dITey4sj_5KgrrI61_k5BTfd1TRi53Mj40LNBlY=.d46e3c3d-c8d9-4631-b5c6-01f490161ae2@github.com>

On Thu, 12 May 2022 15:56:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename method
>
> LGTM.

Thanks @jerboaa  and @iklam . :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From duke at openjdk.java.net  Mon May 16 06:44:52 2022
From: duke at openjdk.java.net (xpbob)
Date: Mon, 16 May 2022 06:44:52 GMT
Subject: Integrated: 8284950: CgroupV1 detection code should consider
 memory.swappiness
In-Reply-To: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
References: <JSpkQq8PeczZFdqhKv4W9VB_XFRw2goRZlHz2--zmpQ=.9d309b94-4d9a-4198-81c7-b7c024245630@github.com>
Message-ID: <me_tQuj23GCd_m3-XqZQv4eaTuU_0uBg-0gOLOHat24=.69a2f683-380d-49ec-9b48-fea9f2eec0c7@github.com>

On Mon, 18 Apr 2022 09:07:31 GMT, xpbob <duke at openjdk.java.net> wrote:

> set memory.swappiness to 0,swap space will not be used 
> determine the value of memory.swappiness
> https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt
> 
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 100.00M
>     Maximum Processes Limit: 4194305 
> 
> =>
> 
>     Memory Limit: 50.00M
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: 50.00M
>     Maximum Processes Limit: 4194305

This pull request has now been integrated.

Changeset: 46d208fb
Author:    bobpengxie <bobpengxie at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/46d208fb1ce9a3d45bee2afda824f15c84a5e4d2
Stats:     142 lines in 4 files changed: 137 ins; 0 del; 5 mod

8284950: CgroupV1 detection code should consider memory.swappiness

Reviewed-by: sgehwolf, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/8285

From dholmes at openjdk.java.net  Mon May 16 07:02:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 16 May 2022 07:02:06 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher
In-Reply-To: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
Message-ID: <OEby8RgrkFmTxiTyo0y58G85dzqm5purLBtcr-9tEwg=.e4ab9e71-8d37-4ffe-9848-4d8041f8e157@github.com>

On Fri, 13 May 2022 08:56:59 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> GCC 12 reports as following:

Simply considering the compiler warning shouldn't `(arg+2) == NULL` actually be `arg[2] = '\0'` ? as we are looking to see if this arg is only three characters: '-', 'J' and '\0'

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From njian at openjdk.java.net  Mon May 16 07:28:42 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 16 May 2022 07:28:42 GMT
Subject: RFR: 8281712: [REDO] AArch64: Implement string_compare intrinsic in
 SVE
Message-ID: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>

This is the REDO of JDK-8269559 and JDK-8275448. Those two backouts finally turned to be some system zlib issue in AArch64 macOS, and is not related to the patch itself. See [1][2] for details.

This patch is generally the same as JDK-8275448, which uses SVE to optimize string_compare intrinsics for long string comparisons. I did a rebase with small tweaks to get better performance on recent Neoverse hardware. Test data on systems with different SVE vector sizes:


   case    delta size  128-bits  256-bits  512-bits
compareToLL  2   24     0.17%     0.58%     0.00%
compareToLL  2   36     0.00%    2.25%      0.04%
compareToLL  2   72     -4.40%   3.87%      -12.82%
compareToLL  2   128    4.55%    58.31%     13.53%
compareToLL  2   256    19.39%   69.77%     82.03%
compareToLL  2   512    1.81%    68.38%     170.93%
compareToLU  2   24     25.57%   46.98%     54.61%
compareToLU  2   36     36.03%   70.26%     94.33%
compareToLU  2   72     35.86%   90.58%     146.04%
compareToLU  2   128    70.82%   119.19%    266.22%
compareToLU  2   256    80.77%   146.33%    420.01%
compareToLU  2   512    94.62%   171.72%    530.87%
compareToUL  2   24     20.82%   34.48%     62.14%
compareToUL  2   36     39.77%   60.79%     69.77%
compareToUL  2   72     35.46%   84.34%     121.90%
compareToUL  2   128    67.77%   110.97%    220.53%
compareToUL  2   256    77.05%   160.29%    331.30%
compareToUL  2   512    91.88%   184.57%    524.21%
compareToUU  2   24     -0.13%   0.40%      0.00%
compareToUU  2   36     -9.18%   12.84%     -13.93%
compareToUU  2   72     1.67%    60.61%     6.69%
compareToUU  2   128    13.51%   60.33%     55.27%
compareToUU  2   256    2.55%    62.17%     153.26%
compareToUU  2   512    4.12%    68.62%     201.68%

JTreg tests passed on SVE hardware.

[1] https://bugs.openjdk.java.net/browse/JDK-8275448
[2] https://bugs.openjdk.java.net/browse/JDK-8282954

-------------

Commit messages:
 - 8281712: [REDO] AArch64: Implement string_compare intrinsic in SVE

Changes: https://git.openjdk.java.net/jdk/pull/8723/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8723&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281712
  Stats: 443 lines in 7 files changed: 433 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8723.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8723/head:pull/8723

PR: https://git.openjdk.java.net/jdk/pull/8723

From jlahoda at openjdk.java.net  Mon May 16 07:53:43 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 16 May 2022 07:53:43 GMT
Subject: Integrated: 8282274: Compiler implementation for Pattern Matching for
 switch (Third Preview)
In-Reply-To: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
References: <o1MFqbmPouyZ0rybPCFjmYyfE_rhvFUC1wLWXM1cF1s=.b2566d30-21a3-4f12-a219-9385740a90a8@github.com>
Message-ID: <H-AnO-2I8KSjndTcCtnYpIFv6t3ber6MJ3OItizv-XA=.f681a57a-1260-44ba-93a3-3edf68f3762a@github.com>

On Mon, 11 Apr 2022 16:37:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a (preliminary) patch for javac implementation for the third preview of pattern matching for switch (type patterns in switches).
> 
> Draft JLS:
> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
> 
> The changes are:
> -there are no guarded patterns anymore, guards are not bound to the CaseElement (JLS 15.28)
> -a new contextual keyword `when` is used to add a guard, instead of `&&`
> -`null` selector value is handled on switch level (if a switch has `case null`, it is used, otherwise a NPE is thrown), rather than on pattern matching level.
> -total patterns are allowed in `instanceof`
> -`java.lang.MatchException` is added for the case where a switch is exhaustive (due to sealed types) at compile-time, but not at runtime.
> 
> Feedback is welcome!
> 
> Thanks!

This pull request has now been integrated.

Changeset: 0155e4b7
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0155e4b76bb0889e516811647aede500a7812db1
Stats:     1093 lines in 56 files changed: 549 ins; 320 del; 224 mod

8282274: Compiler implementation for Pattern Matching for switch (Third Preview)

Co-authored-by: Brian Goetz <briangoetz at openjdk.org>
Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Reviewed-by: mcimadamore, vromero, abimpoudis

-------------

PR: https://git.openjdk.java.net/jdk/pull/8182

From duke at openjdk.java.net  Mon May 16 07:56:40 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Mon, 16 May 2022 07:56:40 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v5]
In-Reply-To: <MYQYuhBdAWz5laM3hVrIlVC7KJQE38AJ-Y-lPbw-mP0=.ef02fbe6-bfc5-49e0-8e30-712c187b0f6c@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <MYQYuhBdAWz5laM3hVrIlVC7KJQE38AJ-Y-lPbw-mP0=.ef02fbe6-bfc5-49e0-8e30-712c187b0f6c@github.com>
Message-ID: <34aWbLZTml1eYUnsbeGKnFhiSM5wfE3hE4myRHB9TGg=.ef7e3bbc-4440-472c-8e78-6a57873489d8@github.com>

On Tue, 10 May 2022 09:57:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing (non-)exhaustiveness for enum.

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout patterns-record-deconstruction3
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

-------------

PR: https://git.openjdk.java.net/jdk/pull/8516

From jpai at openjdk.java.net  Mon May 16 07:57:54 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 16 May 2022 07:57:54 GMT
Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to
 collect data due to permission issues [v2]
In-Reply-To: <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>
References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>
 <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>
Message-ID: <dWZ6UgQCaremz1d_yVaLgBNsWMRZuuIdvS89xyOe0oQ=.af03d843-2dda-4a85-81e3-9e5c8f2f0c77@github.com>

On Fri, 13 May 2022 14:39:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS?
>> 
>> As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command.
>> 
>> Tested locally on macOS by running:
>> 
>> 
>> cd test/failure_handler
>> make clean
>> make test
>> 
>> Then checked the generated environment.html files for the dmesg command output. Looks fine after this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

Thank you Daniel and Lance for the reviews. 

Would anyone from the build team provide any additional reviews?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8703

From jlahoda at openjdk.java.net  Mon May 16 10:39:35 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 16 May 2022 10:39:35 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v6]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <2ghh_OV-ixn0tQEw6NvSOmWoi0LFDTmoGMSGyHwhFwY=.6db7ef79-e984-43ae-b4a1-e287d9cc2211@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Post merge fix.
 - Merge branch 'master' into patterns-record-deconstruction3
 - Fixing (non-)exhaustiveness for enum.
 - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
 - Merge branch 'master' into type-patterns-third
 - Using Type.isRaw instead of checking the AST structure.
 - Exhaustiveness should accept supertypes of the specified type.
 - Renaming the features from deconstruction pattern to record pattern.
 - Fixing guards after record patterns.
 - Raw types are not allowed in record patterns.
 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/0155e4b7...924daa0c

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=05
  Stats: 2255 lines in 50 files changed: 2169 ins; 15 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From dholmes at openjdk.java.net  Mon May 16 11:28:02 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 16 May 2022 11:28:02 GMT
Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to
 collect data due to permission issues [v2]
In-Reply-To: <dWZ6UgQCaremz1d_yVaLgBNsWMRZuuIdvS89xyOe0oQ=.af03d843-2dda-4a85-81e3-9e5c8f2f0c77@github.com>
References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>
 <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>
 <dWZ6UgQCaremz1d_yVaLgBNsWMRZuuIdvS89xyOe0oQ=.af03d843-2dda-4a85-81e3-9e5c8f2f0c77@github.com>
Message-ID: <SztsgzhRWyAIrPuv8d8HA-6nOxul5eNthI0F8CaKU90=.ac97f7d5-d47d-4c4a-b735-0d9551394389@github.com>

On Mon, 16 May 2022 07:54:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright year
>
> Thank you Daniel and Lance for the reviews. 
> 
> Would anyone from the build team like to provide any additional reviews?

@jaikiran  this is more a SQE issue that an build issue. @lmesnik may have an opinion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8703

From thartmann at openjdk.java.net  Mon May 16 12:11:01 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 16 May 2022 12:11:01 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <m6HFoR5G4jcLyFzY1JcZT6oTEISckMd-ahRlqC-dOmg=.dfea1f9d-bd70-48bb-9a09-7efeb942c6a5@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <BZW29EXUQ-S7r_PO1Mcl2j3F-6Tcwezu5JWd00F3pJg=.c56a48e5-0b4c-4999-a69b-bc502abba40f@github.com>
 <m6HFoR5G4jcLyFzY1JcZT6oTEISckMd-ahRlqC-dOmg=.dfea1f9d-bd70-48bb-9a09-7efeb942c6a5@github.com>
Message-ID: <7Kc1dbOWuBDaz9MY5Fv2fxzBObf6nDGL9HIotCiMtik=.b33b0951-4067-4640-af80-54a2defc9d01@github.com>

On Wed, 27 Apr 2022 09:13:34 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
>> However, current implementation is incorrect for negative bytes/shorts.
>> 
>> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
>> 
>>  13     public static void urshift(byte[] src, byte[] dst) {
>>  14         for (int i = 0; i < src.length; i++) {
>>  15             dst[i] = (byte)(src[i] >>> 3);
>>  16         }
>>  17     }
>>  18 
>>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>>  20         int i = 0;
>>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>>  22             var va = ByteVector.fromArray(spec, src, i);
>>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>>  24             vb.intoArray(dst, i);
>>  25         }
>>  26 
>>  27         for (; i < src.length; i++) {
>>  28             dst[i] = (byte)(src[i] >>> 3);
>>  29         }
>>  30     }
>> 
>> 
>> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
>> It took quite a long time to figure out this bug.
>> 
>> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
>> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
>> So this seems unreasonable and unfriendly to Java developers.
>> It would be better to fix it.
>> 
>> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
>> This logic is:
>> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
>> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
>> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
>> 
>> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
>> And many thanks to @fg1417 .
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935
>
>> > > According to the Vector API doc, the LSHR operator computes a>>>(n&(ESIZE*8-1))
>> 
>> Documentation is correct if viewed strictly in context of subword vector lane, JVM internally promotes/sign extends subword type scalar variables into int type, but vectors are loaded from continuous memory holding subwords, it will not be correct for developer to imagine that individual subword type lanes will be upcasted into int lanes before being operated upon.
>> 
>> Thus both java implementation and compiler handling looks correct.
> 
> Thanks @jatin-bhateja for taking a look at this.
> After the discussion, I think it's fine to keep the current implementation of LSHR.
> So we're now fixing the misleading doc here: https://github.com/openjdk/jdk/pull/8291 .
> 
> And I think it would be better to add one more operator for `>>>`.
> Thanks.

@DamonFool should this PR and the JBS issue be closed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From jiefu at openjdk.java.net  Mon May 16 12:21:57 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 16 May 2022 12:21:57 GMT
Subject: RFR: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <m6HFoR5G4jcLyFzY1JcZT6oTEISckMd-ahRlqC-dOmg=.dfea1f9d-bd70-48bb-9a09-7efeb942c6a5@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
 <BZW29EXUQ-S7r_PO1Mcl2j3F-6Tcwezu5JWd00F3pJg=.c56a48e5-0b4c-4999-a69b-bc502abba40f@github.com>
 <m6HFoR5G4jcLyFzY1JcZT6oTEISckMd-ahRlqC-dOmg=.dfea1f9d-bd70-48bb-9a09-7efeb942c6a5@github.com>
Message-ID: <Fba_dgHCNBr7bGmhZ5iOo8VWzuBTO3Ge_6kUyzDKeLw=.f31d0b65-7a5c-49e0-a5f0-5f06e6969fef@github.com>

On Wed, 27 Apr 2022 09:13:34 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
>> However, current implementation is incorrect for negative bytes/shorts.
>> 
>> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
>> 
>>  13     public static void urshift(byte[] src, byte[] dst) {
>>  14         for (int i = 0; i < src.length; i++) {
>>  15             dst[i] = (byte)(src[i] >>> 3);
>>  16         }
>>  17     }
>>  18 
>>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>>  20         int i = 0;
>>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>>  22             var va = ByteVector.fromArray(spec, src, i);
>>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>>  24             vb.intoArray(dst, i);
>>  25         }
>>  26 
>>  27         for (; i < src.length; i++) {
>>  28             dst[i] = (byte)(src[i] >>> 3);
>>  29         }
>>  30     }
>> 
>> 
>> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
>> It took quite a long time to figure out this bug.
>> 
>> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
>> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
>> So this seems unreasonable and unfriendly to Java developers.
>> It would be better to fix it.
>> 
>> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
>> This logic is:
>> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
>> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
>> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
>> 
>> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
>> And many thanks to @fg1417 .
>> 
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935
>
>> > > According to the Vector API doc, the LSHR operator computes a>>>(n&(ESIZE*8-1))
>> 
>> Documentation is correct if viewed strictly in context of subword vector lane, JVM internally promotes/sign extends subword type scalar variables into int type, but vectors are loaded from continuous memory holding subwords, it will not be correct for developer to imagine that individual subword type lanes will be upcasted into int lanes before being operated upon.
>> 
>> Thus both java implementation and compiler handling looks correct.
> 
> Thanks @jatin-bhateja for taking a look at this.
> After the discussion, I think it's fine to keep the current implementation of LSHR.
> So we're now fixing the misleading doc here: https://github.com/openjdk/jdk/pull/8291 .
> 
> And I think it would be better to add one more operator for `>>>`.
> Thanks.

> @DamonFool should this PR and the JBS issue be closed?

Okay.
Let's close it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From jiefu at openjdk.java.net  Mon May 16 12:21:59 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 16 May 2022 12:21:59 GMT
Subject: Withdrawn: 8284932: [Vector API] Incorrect implementation of LSHR
 operator for negative byte/short elements
In-Reply-To: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
References: <yvDqcKWoM46V6nPk9JBhMNihNrfVWjrhT7NKmdh5HrU=.2c0e5b5c-449d-45d8-a207-cfc529e4b332@github.com>
Message-ID: <eWjCqw_REdthmCVmkcovpQa4XIMn-yCSKAiwq95BL98=.d0876c80-ba7f-4faf-998e-81ddc98b05be@github.com>

On Sun, 17 Apr 2022 14:35:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> According to the Vector API doc, the `LSHR` operator computes `a>>>(n&(ESIZE*8-1))`.
> However, current implementation is incorrect for negative bytes/shorts.
> 
> The background is that one of our customers try to vectorize `urshift` with `urshiftVector` like the following.
> 
>  13     public static void urshift(byte[] src, byte[] dst) {
>  14         for (int i = 0; i < src.length; i++) {
>  15             dst[i] = (byte)(src[i] >>> 3);
>  16         }
>  17     }
>  18 
>  19     public static void urshiftVector(byte[] src, byte[] dst) {
>  20         int i = 0;
>  21         for (; i < spec.loopBound(src.length); i +=spec.length()) {
>  22             var va = ByteVector.fromArray(spec, src, i);
>  23             var vb = va.lanewise(VectorOperators.LSHR, 3);
>  24             vb.intoArray(dst, i);
>  25         }
>  26 
>  27         for (; i < src.length; i++) {
>  28             dst[i] = (byte)(src[i] >>> 3);
>  29         }
>  30     }
> 
> 
> Unfortunately and to our surprise, code at line28 computes different results with code at line23.
> It took quite a long time to figure out this bug.
> 
> The root cause is that current implemenation of Vector API can't compute the  unsigned right shift results as what is done for scalar `>>>` for negative byte/short elements.
> Actually, current implementation will do `(a & 0xFF) >>> (n & 7)` [1] for all bytes, which is unable to compute the vectorized `>>>` for negative bytes.
> So this seems unreasonable and unfriendly to Java developers.
> It would be better to fix it.
> 
> The key idea to support unsigned right shift of negative bytes/shorts is just to replace the unsigned right shift operation with the signed right shift operation.
> This logic is:
> - For byte elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 24.
> - For short elements, unsigned right shift is equal to signed right shift if the shift_cnt <= 16.
> - For Vector API, the shift_cnt will be masked to shift_cnt <= 7 for bytes and shift_cnt <= 15 for shorts.
> 
> I just learned this idea from https://github.com/openjdk/jdk/pull/7979 .
> And many thanks to @fg1417 .
> 
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java#L935

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8276

From ysuenaga at openjdk.java.net  Mon May 16 12:35:48 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 16 May 2022 12:35:48 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher
In-Reply-To: <OEby8RgrkFmTxiTyo0y58G85dzqm5purLBtcr-9tEwg=.e4ab9e71-8d37-4ffe-9848-4d8041f8e157@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
 <OEby8RgrkFmTxiTyo0y58G85dzqm5purLBtcr-9tEwg=.e4ab9e71-8d37-4ffe-9848-4d8041f8e157@github.com>
Message-ID: <NeeCb_cKNgNHndpO46utny1QkraFs-ffW8mc0T1hxDk=.b7a95730-108e-4f79-821b-a2ac4d507d00@github.com>

On Mon, 16 May 2022 06:58:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Simply considering the compiler warning shouldn't `(arg+2) == NULL` actually be `arg[2] == '\0'` ? as we are looking to see if this arg is only three characters: '-', 'J' and '\0'

Yeah, I thought that first, but I think better of keeping similar code because the result (element of `nargv`) will be used as loop condition (see description of this PR).

In addition, subsequent codes consider this case (`-J` only)  to be an error as following:


1633     for (i = 0; i < argc; i++) {
1634         char *arg = argv[i];
1635         if (arg[0] == '-' && arg[1] == 'J') {
1636             if (arg[2] == '\0') {
1637                 JLI_ReportErrorMessage(ARG_ERROR3);
1638                 exit(1);
1639             }
1640             *nargv++ = arg + 2;
1641         }
1642     }


However `jargv` is builtin arguments, not user specified arguments as I wrote the description of this PR. So I think we can ignore it, but it would be nice if we can see it in trace logs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From dholmes at openjdk.java.net  Mon May 16 13:23:47 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 16 May 2022 13:23:47 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher
In-Reply-To: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
Message-ID: <EqpBY4VoH-sAMZTzPc2VsSFs51Tp0ti50UaPwORgqPE=.b7f8f052-cf24-44fb-b5b4-9c851942cb25@github.com>

On Fri, 13 May 2022 08:56:59 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> GCC 12 reports as following:

I don't recall what "builtin arguments" means. Can you tell me how we would actually hit this conditions such that we string dup and  the null string? Or are you saying this is actually an unreachable case: the check for NULL is always false and the actual  string is never null anyway?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From dholmes at openjdk.java.net  Mon May 16 13:26:49 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 16 May 2022 13:26:49 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher
In-Reply-To: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
Message-ID: <MkjfH-dbIvgCqpesYJVCt0E9JLNhl8OpzzxtUuiCjQI=.7273bfd3-835f-4c2b-8515-6a42a62b207f@github.com>

On Fri, 13 May 2022 08:56:59 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> GCC 12 reports as following:

src/java.base/share/native/libjli/java.c line 1632:

> 1630:                 if (JLI_IsTraceLauncher()) {
> 1631:                     printf("Empty option: jargv[%d]\n", i);
> 1632:                 }

I'd say this is an error as well - but a developer error rather than end-user.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From jvernee at openjdk.java.net  Mon May 16 14:38:46 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 16 May 2022 14:38:46 GMT
Subject: Integrated: 8286390: Address possibly lossy conversions in
 jdk.incubator.foreign moved to java.base
In-Reply-To: <Wg0iUAj6VgPCUV3oTZ1ZD9xRNYAQB5ReMkQOUgYBkzM=.02279d0d-729f-4efc-b0f0-bbb27ba6eeba@github.com>
References: <Wg0iUAj6VgPCUV3oTZ1ZD9xRNYAQB5ReMkQOUgYBkzM=.02279d0d-729f-4efc-b0f0-bbb27ba6eeba@github.com>
Message-ID: <0Pynqny2exdSZBS2IcZeD86QKh7mZL7NVvxolb2AFmM=.8bca5c25-344b-479e-940a-d5351e8a182a@github.com>

On Fri, 13 May 2022 10:04:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Address possible lossy conversion warning in `ProgrammableInvoker`.
> 
> Testing: `run-test-jdk_foreign`, testing with patch from https://github.com/openjdk/jdk/pull/8599 to see if the warning is gone.

This pull request has now been integrated.

Changeset: 743c7797
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/743c779712184ae41e7be4078b0d485ebc51c845
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8286390: Address possibly lossy conversions in jdk.incubator.foreign moved to java.base

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8697

From asotona at openjdk.java.net  Mon May 16 14:45:25 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 16 May 2022 14:45:25 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v7]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <B9n9ovVUUAPav2KdXUFCOizjfBhzhONYzbossdB5IoQ=.dcca8271-3116-4026-a51a-0afa592cb3ad@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   jdk.internal.le make patch to disable warnings
 - 8244681: Add a warning for possibly lossy conversion in compound assignments

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06
  Stats: 444 lines in 21 files changed: 441 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From jvernee at openjdk.java.net  Mon May 16 14:52:04 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 16 May 2022 14:52:04 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v19]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <zP-6FwUqGKFgcIv27R7kQHXCV2EMGaLmDKxe1FF9byU=.daf5e59a-7de0-47ae-b8a0-e6e9cf5a205a@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Fix failure with SPEC disabled (accidentally dropped change)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/2ea5bc94..ff8835ee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=17-18

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From duke at openjdk.java.net  Mon May 16 14:55:21 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 16 May 2022 14:55:21 GMT
Subject: RFR: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts
Message-ID: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>

Please review these simple changes in jdk.internal.math.[Double|Float]Consts

-------------

Commit messages:
 - 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts

Changes: https://git.openjdk.java.net/jdk/pull/8729/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8729&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286810
  Stats: 37 lines in 2 files changed: 8 ins; 5 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8729.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8729/head:pull/8729

PR: https://git.openjdk.java.net/jdk/pull/8729

From asotona at openjdk.java.net  Mon May 16 14:58:33 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 16 May 2022 14:58:33 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v8]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <6fMaRe1U4N-Uz4oe8QKOqIwy-bqkQRVR75XJJpLSXgY=.c8072af3-f0e1-430e-9ab2-33db617c5d77@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  8244681: Add a warning for possibly lossy conversion in compound assignments
  re-enabled warnings for java.base, java.rmi and java.smartcardio

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/a72644e9..74f9f4b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=06-07

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From duke at openjdk.java.net  Mon May 16 15:32:41 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 16 May 2022 15:32:41 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v3]
In-Reply-To: <lB5ub_ZJTwl8kSN6S7PBAa1FS66R68ztr_rIaMB3UAQ=.bf5d56f5-1efd-4a8f-8cdd-8dfb095fc647@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
 <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com>
 <FAz94giFgpWhvP92dNc3xetP7uZnL6HFvjm_HIx4-yc=.050146cc-fa6c-4290-a1f0-118bbc79e436@github.com>
 <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com>
 <lB5ub_ZJTwl8kSN6S7PBAa1FS66R68ztr_rIaMB3UAQ=.bf5d56f5-1efd-4a8f-8cdd-8dfb095fc647@github.com>
Message-ID: <acEJ1Y7t06mvfzuypr1qxVatndsfmH6zXzYJk3yH_fM=.c8af8378-9d13-457c-aca5-c29345c31927@github.com>

On Fri, 13 May 2022 13:36:52 GMT, ExE Boss <duke at openjdk.java.net> wrote:

> So if anything, the List.of(?) call should be moved into the ProxyMethod constructor. And maybe the call to Method.getExceptionTypes() should be changed to Method.getSharedExceptionTypes()

Makes sense. Do you want me to do this within this PR (this would be a deviation from ticket's target), or it's better to create another one?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From bpb at openjdk.java.net  Mon May 16 15:44:56 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 16 May 2022 15:44:56 GMT
Subject: RFR: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF [v3]
In-Reply-To: <zpTKzARA3v4-gSW3sSrfHfqRgdkC7yrh8MqtnFKjAVI=.3ce36d05-dc0b-4f6b-8e31-6de513be9fa2@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
 <Ek-L8Fh56fWZgWLvXKYR3qH2ol2AYjKMrWRqdQgRfjs=.3ea834cf-f3e2-4f8a-a30f-cad7320cf6d0@github.com>
 <zpTKzARA3v4-gSW3sSrfHfqRgdkC7yrh8MqtnFKjAVI=.3ce36d05-dc0b-4f6b-8e31-6de513be9fa2@github.com>
Message-ID: <tSawFAxLzLdw7zNtAn4-8LeC6a_JTFDLdnzwZyiYZqo=.bceba408-a21f-4e7d-a964-9a725f74bdb8@github.com>

On Thu, 12 May 2022 19:00:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> In the throws clauses, I think I would have put the additional conditional at the end of the sentence since the existing throws text corresponds to the exception. But the logic is correct as is.

I put it at the beginning as that is the ordering but I see  your point.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8664

From bpb at openjdk.java.net  Mon May 16 15:44:58 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 16 May 2022 15:44:58 GMT
Subject: Integrated: 8286200: SequenceInputStream::read(b, off,
 0) returns -1 at EOF
In-Reply-To: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
References: <PorHayVPdFf7iYP6I9jXiiH6M_lfNJ2dnoeD5EJU4JE=.649eb475-ce7d-47d2-bf04-ba71dace359b@github.com>
Message-ID: <abhjs14Pwgehj2crhoqmyjK-a-LO29MFyiwW6l59nc8=.4209fcb3-8c81-4703-b84c-827696e0eaa0@github.com>

On Wed, 11 May 2022 20:47:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the specification of `SequenceInputStream.read(byte[],int,int)` to indicate that `-1` is returned at the EOF of the last stream even if `len` is zero.

This pull request has now been integrated.

Changeset: dbd37370
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dbd3737085d6e343a286f14556b9f49d71b4f959
Stats:     9 lines in 1 file changed: 3 ins; 0 del; 6 mod

8286200: SequenceInputStream::read(b, off, 0) returns -1 at EOF

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8664

From rriggs at openjdk.java.net  Mon May 16 15:46:49 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 16 May 2022 15:46:49 GMT
Subject: RFR: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts
In-Reply-To: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
References: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
Message-ID: <PsnVl32VNtTMS0fZOtkDRI0ZACmG88ZxLT7AlGH3xYg=.65b2ee3a-1c3d-4b6c-abe4-b71b3bc35bd9@github.com>

On Mon, 16 May 2022 14:48:43 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review these simple changes in jdk.internal.math.[Double|Float]Consts

src/java.base/share/classes/jdk/internal/math/DoubleConsts.java line 28:

> 26: package jdk.internal.math;
> 27: 
> 28: import static java.lang.Double.*;

I'd rather see explicit static imports, especially if there is any ambiguity as to where they come from.
When using ordinary text search in a file, it can quickly identify a static import as the source of the symbol.
As in this case where the same symbol has different values for Float vs Double. YMMV

-------------

PR: https://git.openjdk.java.net/jdk/pull/8729

From naoto at openjdk.java.net  Mon May 16 15:48:59 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 16 May 2022 15:48:59 GMT
Subject: Integrated: 8285844: TimeZone.getTimeZone(ZoneOffset) does not work
 for all ZoneOffsets and returns GMT unexpected
In-Reply-To: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
References: <QvoruBsmSjSrN-8Sj0WwYh_ViW-ZnTrQmO2s_L4XYa8=.eebd50c6-8aa3-4e50-afea-ef8cf99696c0@github.com>
Message-ID: <hHka_VY2N9wuxuY3oQFXzgApj_AqqlPEAXXFZmI5igo=.3252288b-78a1-4215-b45e-41f0b39b36b3@github.com>

On Mon, 9 May 2022 18:59:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

This pull request has now been integrated.

Changeset: b884db8f
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b884db8f7c03fd300becaeb9d572f3b2c18351ae
Stats:     155 lines in 4 files changed: 110 ins; 0 del; 45 mod

8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

Reviewed-by: uschindler, scolebourne, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Mon May 16 15:49:46 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 16 May 2022 15:49:46 GMT
Subject: Integrated: 8286399: Address possibly lossy conversions in JDK Build
 Tools
In-Reply-To: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com>
References: <1KwJ-hmtKPLBqoBGrkFUkV6dbx9YH2Ijpf_oGfS_0VE=.e7489315-bd25-4f3e-add6-5fa041e5b4fa@github.com>
Message-ID: <28rLfqfgKslQOUsIr4ss1KOIzvxM5M59rW6o_D_t2H8=.1b45f75e-4a2a-4d2d-b1e9-98fc6425cb33@github.com>

On Fri, 13 May 2022 17:05:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Applied required casts for the upcoming warning. Verified by cherry-picking Adam's patch.

This pull request has now been integrated.

Changeset: c044cb83
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c044cb8346bb8fbba46db1debe921cf96885ada0
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8286399: Address possibly lossy conversions in JDK Build Tools

Reviewed-by: rriggs, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/8706

From duke at openjdk.java.net  Mon May 16 15:54:25 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 16 May 2022 15:54:25 GMT
Subject: RFR: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts [v2]
In-Reply-To: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
References: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
Message-ID: <aNOaq_6v2Z_RKzNDWqoqJjcVX9tg05Y42XevAg_odsc=.9d6fab0e-a4a0-44a2-92d8-b90c338fb216@github.com>

> Please review these simple changes in jdk.internal.math.[Double|Float]Consts

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8729/files
  - new: https://git.openjdk.java.net/jdk/pull/8729/files/0091e546..3c6be86c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8729&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8729&range=00-01

  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8729.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8729/head:pull/8729

PR: https://git.openjdk.java.net/jdk/pull/8729

From bpb at openjdk.java.net  Mon May 16 15:54:25 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 16 May 2022 15:54:25 GMT
Subject: RFR: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts [v2]
In-Reply-To: <aNOaq_6v2Z_RKzNDWqoqJjcVX9tg05Y42XevAg_odsc=.9d6fab0e-a4a0-44a2-92d8-b90c338fb216@github.com>
References: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
 <aNOaq_6v2Z_RKzNDWqoqJjcVX9tg05Y42XevAg_odsc=.9d6fab0e-a4a0-44a2-92d8-b90c338fb216@github.com>
Message-ID: <h6EkQyD0v656bg1zWcxeFY9Nt-_-tHey6BseL90SHmo=.e872df80-f7d2-4bda-95d5-fd29dccb2e4a@github.com>

On Mon, 16 May 2022 15:51:43 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Please review these simple changes in jdk.internal.math.[Double|Float]Consts
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8729

From duke at openjdk.java.net  Mon May 16 15:54:26 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 16 May 2022 15:54:26 GMT
Subject: RFR: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts
In-Reply-To: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
References: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
Message-ID: <K5QbF9HFgVEtdlVfgzUcLzvJV-Izb2AJfcuKbHvdec0=.1765667d-3a2a-4ae9-b5ee-175d2a29c6f6@github.com>

On Mon, 16 May 2022 14:48:43 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review these simple changes in jdk.internal.math.[Double|Float]Consts

Adjusted

-------------

PR: https://git.openjdk.java.net/jdk/pull/8729

From bpb at openjdk.java.net  Mon May 16 15:54:27 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 16 May 2022 15:54:27 GMT
Subject: RFR: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts [v2]
In-Reply-To: <PsnVl32VNtTMS0fZOtkDRI0ZACmG88ZxLT7AlGH3xYg=.65b2ee3a-1c3d-4b6c-abe4-b71b3bc35bd9@github.com>
References: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
 <PsnVl32VNtTMS0fZOtkDRI0ZACmG88ZxLT7AlGH3xYg=.65b2ee3a-1c3d-4b6c-abe4-b71b3bc35bd9@github.com>
Message-ID: <LE3DdKm2WuDakBn925rAv7T-wzLM0DoGejZ2Fap7Blo=.9fb688f7-f521-4c9a-ab59-dc2e458b3289@github.com>

On Mon, 16 May 2022 15:43:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts
>
> src/java.base/share/classes/jdk/internal/math/DoubleConsts.java line 28:
> 
>> 26: package jdk.internal.math;
>> 27: 
>> 28: import static java.lang.Double.*;
> 
> I'd rather see explicit static imports, especially if there is any ambiguity as to where they come from.
> When using ordinary text search in a file, it can quickly identify a static import as the source of the symbol.
> As in this case where the same symbol has different values for Float vs Double. YMMV

I concur.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8729

From rriggs at openjdk.java.net  Mon May 16 16:02:04 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 16 May 2022 16:02:04 GMT
Subject: RFR: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts [v2]
In-Reply-To: <aNOaq_6v2Z_RKzNDWqoqJjcVX9tg05Y42XevAg_odsc=.9d6fab0e-a4a0-44a2-92d8-b90c338fb216@github.com>
References: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
 <aNOaq_6v2Z_RKzNDWqoqJjcVX9tg05Y42XevAg_odsc=.9d6fab0e-a4a0-44a2-92d8-b90c338fb216@github.com>
Message-ID: <rmVh5cvjY-8NYJ9rylLsoViFc0G3B_ijtyXAaGfQ3sY=.23384453-ea7b-4eb4-b413-575182c1a0bf@github.com>

On Mon, 16 May 2022 15:54:25 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Please review these simple changes in jdk.internal.math.[Double|Float]Consts
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts

LGTM, thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8729

From duke at openjdk.java.net  Mon May 16 16:02:05 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 16 May 2022 16:02:05 GMT
Subject: RFR: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts [v2]
In-Reply-To: <aNOaq_6v2Z_RKzNDWqoqJjcVX9tg05Y42XevAg_odsc=.9d6fab0e-a4a0-44a2-92d8-b90c338fb216@github.com>
References: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
 <aNOaq_6v2Z_RKzNDWqoqJjcVX9tg05Y42XevAg_odsc=.9d6fab0e-a4a0-44a2-92d8-b90c338fb216@github.com>
Message-ID: <yYjx7sS4AcmKKhftGqWxE6rfpMbPtf_9PdrihqrQCVU=.353f2602-7825-42b5-ae77-e92632a957cf@github.com>

On Mon, 16 May 2022 15:54:25 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Please review these simple changes in jdk.internal.math.[Double|Float]Consts
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts

Will wait 24 hours before integrating

-------------

PR: https://git.openjdk.java.net/jdk/pull/8729

From jvernee at openjdk.java.net  Mon May 16 16:06:24 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 16 May 2022 16:06:24 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v20]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <M2wGN_ycUNHO7OkGFDUxgpee_EOsU034iikO_eBWO4w=.1fbaa1cf-b8c3-4e11-a4ab-a82136992131@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup UL usage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/ff8835ee..d611f365

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=18-19

  Stats: 14 lines in 5 files changed: 2 ins; 1 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Mon May 16 16:06:25 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 16 May 2022 16:06:25 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v19]
In-Reply-To: <zP-6FwUqGKFgcIv27R7kQHXCV2EMGaLmDKxe1FF9byU=.daf5e59a-7de0-47ae-b8a0-e6e9cf5a205a@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <zP-6FwUqGKFgcIv27R7kQHXCV2EMGaLmDKxe1FF9byU=.daf5e59a-7de0-47ae-b8a0-e6e9cf5a205a@github.com>
Message-ID: <UqFwdgktxChwh8h9USmvWlQGxzSLTJ3E29bDMIejiLs=.00fe189c-e971-4e15-8e2c-b1e26f002980@github.com>

On Mon, 16 May 2022 14:52:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
>> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
>> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
>> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix failure with SPEC disabled (accidentally dropped change)

@robehn found a test failure in a non-default configuration that I've fixed [1] (it was addressed in the panama repo by a different patch). I've also cleaned up use of UL a bit [2]: the `panama` tag was renamed to `foreign` and I've added the `downcall` and `upcall` tags as well, for down/up call logging respectively. This is now all under NOT_PRODUCT.

[1]: https://github.com/openjdk/jdk/pull/7959/commits/ff8835ee99203e94fb216c5bd7cf1ce610d5737f
[2]: https://github.com/openjdk/jdk/pull/7959/commits/d611f365ade15cd7a7d005547814ce88fff0ca1a

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From darcy at openjdk.java.net  Mon May 16 16:10:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 16 May 2022 16:10:42 GMT
Subject: Integrated: JDK-8286760: Update citation of "Effective Java" second
 edition to third edition
In-Reply-To: <hP5Mac_L0h-A5SHEW3vOYSPTdagKQb681icbJ1DMWMo=.a8fa9a87-f30a-40c3-969b-7ac55267c249@github.com>
References: <hP5Mac_L0h-A5SHEW3vOYSPTdagKQb681icbJ1DMWMo=.a8fa9a87-f30a-40c3-969b-7ac55267c249@github.com>
Message-ID: <tsYXNYkLmdAujskDUo1dIdO7BdB5Q_LSEkjeiFxEE0c=.dfeebde5-cdec-4592-b246-e965de12ade2@github.com>

On Fri, 13 May 2022 21:17:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update reference to the latest "Effective Java" version and switch to cite tags.

This pull request has now been integrated.

Changeset: 4bc7b7df
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4bc7b7df0421f74c95421c01ee573a2ec9d6805c
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8286760: Update citation of "Effective Java" second edition to third edition

Reviewed-by: bpb, prappo

-------------

PR: https://git.openjdk.java.net/jdk/pull/8707

From jvernee at openjdk.java.net  Mon May 16 16:15:49 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 16 May 2022 16:15:49 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v21]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Missing ASSERT -> NOT_PRODUCT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/d611f365..406f3e83

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=19-20

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From darcy at openjdk.java.net  Mon May 16 16:18:39 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 16 May 2022 16:18:39 GMT
Subject: RFR: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts [v2]
In-Reply-To: <aNOaq_6v2Z_RKzNDWqoqJjcVX9tg05Y42XevAg_odsc=.9d6fab0e-a4a0-44a2-92d8-b90c338fb216@github.com>
References: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
 <aNOaq_6v2Z_RKzNDWqoqJjcVX9tg05Y42XevAg_odsc=.9d6fab0e-a4a0-44a2-92d8-b90c338fb216@github.com>
Message-ID: <X7O-kk25sfNcvTDP8uofyDobjCp4UGps1hw0OAhIE7s=.044ee567-bab8-4185-a1a3-e4350338215d@github.com>

On Mon, 16 May 2022 15:54:25 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Please review these simple changes in jdk.internal.math.[Double|Float]Consts
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts

Looks fine; at your option, add a comment somewhere to setting the bias fields to explicitly indicate what the value is.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8729

From joehw at openjdk.java.net  Mon May 16 16:29:34 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 16 May 2022 16:29:34 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <ZbzIYm_ACXidlRDyVYZ8H73rZmx11NBW9zntTUW-PpM=.e0cab1f9-9b45-4e41-a53b-56fd7e14d8f9@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
 <ZbzIYm_ACXidlRDyVYZ8H73rZmx11NBW9zntTUW-PpM=.e0cab1f9-9b45-4e41-a53b-56fd7e14d8f9@github.com>
Message-ID: <OMZcH8oFBqLBTxxWZKy4ZVlFJURdHx6CexmwnOzH0uk=.dc726139-e0b7-4acd-acdb-d71b80ae0a18@github.com>

On Fri, 13 May 2022 18:51:47 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Shruthi 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:
>> 
>>   Modify copyright year
>
> Did you mean the failure (Pre-submit tests - Linux x86 - Test (tier1) ) above?  That's not related to your change.

> @JoeWang-Java Yes. Shall I comment as **integrate** then?

Yes, please go ahead with integrate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Mon May 16 16:29:34 2022
From: duke at openjdk.java.net (Shruthi)
Date: Mon, 16 May 2022 16:29:34 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
Message-ID: <SIOf_iDu98EYNSd05Gw-B273XHmmcR4ybQVLBQP-m-M=.328bdc92-2f2c-4ad9-b81a-0c0098591671@github.com>

On Thu, 12 May 2022 18:02:26 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi 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:
> 
>   Modify copyright year

`integrate`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Mon May 16 16:31:30 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 16 May 2022 16:31:30 GMT
Subject: RFR: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts [v3]
In-Reply-To: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
References: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
Message-ID: <D6zQ0U9qGBEVN0hthePqzhTZcCwV6oXGT-vDA4BsAiY=.9004f0c2-a7bf-4bf9-9af1-126598e5ad04@github.com>

> Please review these simple changes in jdk.internal.math.[Double|Float]Consts

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8729/files
  - new: https://git.openjdk.java.net/jdk/pull/8729/files/3c6be86c..af257f81

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8729&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8729&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8729.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8729/head:pull/8729

PR: https://git.openjdk.java.net/jdk/pull/8729

From jvernee at openjdk.java.net  Mon May 16 16:36:35 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 16 May 2022 16:36:35 GMT
Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer
In-Reply-To: <zeaLhFMyC1279aCYqNzyT23OI6AXiUxzkWNS68yJbQs=.55dd8eec-7f94-4897-9cab-2d4485ff05cc@github.com>
References: <zeaLhFMyC1279aCYqNzyT23OI6AXiUxzkWNS68yJbQs=.55dd8eec-7f94-4897-9cab-2d4485ff05cc@github.com>
Message-ID: <yp2FIHU-RQKMP1vy1kZ_YFAGKaiw0ErW8LmGQQDwBeg=.59551902-2f66-4ca6-8011-36e0e833c252@github.com>

On Fri, 13 May 2022 12:33:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`.
> This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function.
> 
> We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`.
> So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`.
> 
> In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case.

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 572:

> 570:             return new NativeMemorySegmentImpl(bbAddress + (pos << scaleFactor), size << scaleFactor, modes, bufferSession);
> 571:         } else {
> 572:             // we can ignore scale factor here, a mapped buffer is always a byte buffer, so scaleFactor == 1.

Suggestion:

            // we can ignore scale factor here, a mapped buffer is always a byte buffer, so scaleFactor == 0.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8701

From joehw at openjdk.java.net  Mon May 16 16:38:34 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 16 May 2022 16:38:34 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <SIOf_iDu98EYNSd05Gw-B273XHmmcR4ybQVLBQP-m-M=.328bdc92-2f2c-4ad9-b81a-0c0098591671@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
 <SIOf_iDu98EYNSd05Gw-B273XHmmcR4ybQVLBQP-m-M=.328bdc92-2f2c-4ad9-b81a-0c0098591671@github.com>
Message-ID: <LmVzlDFeFGfLbmW_6747jsGrMbWQCplLNGJDnYzE1hs=.f88c4029-cce2-4abd-b57e-2cc592ce3686@github.com>

On Mon, 16 May 2022 16:26:41 GMT, Shruthi <duke at openjdk.java.net> wrote:

> `integrate`

I think you missed slash, it's slash integrate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From duke at openjdk.java.net  Mon May 16 16:38:36 2022
From: duke at openjdk.java.net (Shruthi)
Date: Mon, 16 May 2022 16:38:36 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
Message-ID: <IrEGv8YNAW0EZP5OYpMsxrrGQP_os0ADgHGG7UN8se0=.539d0ff4-e63c-4cb3-ade2-0e1478becc9a@github.com>

On Thu, 12 May 2022 18:02:26 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi 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:
> 
>   Modify copyright year

`/integrate`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From darcy at openjdk.java.net  Mon May 16 16:43:57 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 16 May 2022 16:43:57 GMT
Subject: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses [v2]
In-Reply-To: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
References: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
Message-ID: <y1z0AMqhfHBOCwV3nHe1VUEe8u2DAtJPd0FQXQCSPP4=.9ef6e5f6-4018-4420-bc59-8f9427b95e55@github.com>

> Make the javadoc in the InputStream and OutputStream subclasses in core libs DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in client libs will be done another a separate bug.) When the time comes, will do any necessary merging for the changes in[JDK-8286200.
> 
> Please also review the CSR to cover the introduction of implspec and implNote tags: https://bugs.openjdk.java.net/browse/JDK-8286784

Joe Darcy 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 'master' into JDK-8286783
 - JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8717/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8717&range=01
  Stats: 189 lines in 13 files changed: 49 ins; 45 del; 95 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8717.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8717/head:pull/8717

PR: https://git.openjdk.java.net/jdk/pull/8717

From jvernee at openjdk.java.net  Mon May 16 16:45:40 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 16 May 2022 16:45:40 GMT
Subject: RFR: 8286756: Cleanup foreign API benchmarks
In-Reply-To: <548L9IsOJxCm2fzP-G5IzPkTLsu9UXHM8MW1_Ereb-M=.af48c268-0144-4200-ae98-7fad29f23a3f@github.com>
References: <548L9IsOJxCm2fzP-G5IzPkTLsu9UXHM8MW1_Ereb-M=.af48c268-0144-4200-ae98-7fad29f23a3f@github.com>
Message-ID: <bRlJqMyW9pX8wnM6wGXai-jO-vNH2VH1BPo3i8yT0SI=.b31b9d0b-7693-4ded-a787-e14bb90b0469@github.com>

On Fri, 13 May 2022 15:48:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This simple patch regularizes some of the foreign API benchmarks. Some of the changes are:
> 
> * use of capital names for var handle and layout constants
> * move shared layout and var handle constants in a new superclass, `JavaLayouts`
> * regularize aligned vs. unaligned benchmarks, especially in `LoopOverNonConstantHeap`. Since the API now aligns layouts by default, where the benchmark name doesn't say anything we assume aligned layout; for benchmarks that test specifically the use of unaligned layouts, we use the `_unaligned` prefix.

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8705

From darcy at openjdk.java.net  Mon May 16 16:53:34 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 16 May 2022 16:53:34 GMT
Subject: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses [v3]
In-Reply-To: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
References: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
Message-ID: <xlIo8IBwJymp0A7EuHnSNnwRiVd8HDaWMHtjOO8Ob78=.88d6fd0c-3d3e-45af-ad7e-fd7b1e8507af@github.com>

> Make the javadoc in the InputStream and OutputStream subclasses in core libs DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in client libs will be done another a separate bug.) When the time comes, will do any necessary merging for the changes in[JDK-8286200.
> 
> Please also review the CSR to cover the introduction of implspec and implNote tags: https://bugs.openjdk.java.net/browse/JDK-8286784

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright, change whitespace.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8717/files
  - new: https://git.openjdk.java.net/jdk/pull/8717/files/c84ef79a..07e8a6a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8717&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8717&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8717.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8717/head:pull/8717

PR: https://git.openjdk.java.net/jdk/pull/8717

From darcy at openjdk.java.net  Mon May 16 17:01:38 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 16 May 2022 17:01:38 GMT
Subject: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses [v3]
In-Reply-To: <luHclXr6lXAgEGyOtTlIABc2mQmms2okpJY9EAcilIg=.d6f32599-a238-489a-bcc4-a64955767210@github.com>
References: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
 <luHclXr6lXAgEGyOtTlIABc2mQmms2okpJY9EAcilIg=.d6f32599-a238-489a-bcc4-a64955767210@github.com>
Message-ID: <OWNnbVc521H9eocqTtLzgWieKAv0DoNC2nKN82c54zY=.2b85e8d2-466a-4543-a255-059a014de3df@github.com>

On Sun, 15 May 2022 21:16:53 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 1. One the one hand, it's not clear to me what criterion was used for adding `@Override` annotations. On the other hand, the more `@Override` annotations a codebase has, the better.
> 
>     2. Have you compared the resulting documentation before and after the change? Aside from added `@implSpec` and `@implNote`, were there anything anything different?
> 
>     3. I wonder if it makes sense to also reduce the size of the doc comments by changing explicit documentation inheritance for the `@param` and `@return` tags to implicit one, i.e. removing the tags on the overrider's side.

I added the `@Override` annotations to methods I reviewed and/or updated; it was not necessarily an exhaustive process. I have not run specdiff to double-check the expected changes; it would be more thorough to do so. The intention is to only have minor wording changes apart from the `@implSpec` and `@implNote` tags. Stylistically, I'd prefer the explicit `@foo {@inhertiDoc}` idiom to indicate the code just want to use the javadoc from a supertype.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8717

From alanb at openjdk.java.net  Mon May 16 17:01:38 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 16 May 2022 17:01:38 GMT
Subject: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses [v3]
In-Reply-To: <OWNnbVc521H9eocqTtLzgWieKAv0DoNC2nKN82c54zY=.2b85e8d2-466a-4543-a255-059a014de3df@github.com>
References: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
 <luHclXr6lXAgEGyOtTlIABc2mQmms2okpJY9EAcilIg=.d6f32599-a238-489a-bcc4-a64955767210@github.com>
 <OWNnbVc521H9eocqTtLzgWieKAv0DoNC2nKN82c54zY=.2b85e8d2-466a-4543-a255-059a014de3df@github.com>
Message-ID: <5WUDim6rqF26iKsC1YExEUrNlILZqtWKD7uwlHVNxlA=.b55ace81-7da6-47ad-a64e-765d772c3eab@github.com>

On Mon, 16 May 2022 16:56:00 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I added the `@Override` annotations to methods I reviewed and/or updated; it was not necessarily an exhaustive process. 

Yeah, there are inconsistencies as a result and I think we should go the extra mile and add to the methods such as readAllBbytes, readNBytes that weren't changed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8717

From itakiguchi at openjdk.java.net  Mon May 16 17:19:40 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 16 May 2022 17:19:40 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v8]
In-Reply-To: <9uYukMkKKeD4KCdJamFXCQ3izhcDC2XBqV-QknU9Z1Y=.84a824f8-e319-4af1-9c92-c5fc2bc4565c@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <L1PK61h3l9Oykbzpg0UXFu8v1cA2pJqjxaxs-zFHW60=.75aad5fe-1814-4b1f-8660-68afe1928e63@github.com>
 <9uYukMkKKeD4KCdJamFXCQ3izhcDC2XBqV-QknU9Z1Y=.84a824f8-e319-4af1-9c92-c5fc2bc4565c@github.com>
Message-ID: <fMVjXcsuYYBThCM0SuFmCHaOVcSWlOftrjAzm-4hFek=.ba7676b8-a6da-4439-8757-d9c9592cd473@github.com>

On Fri, 13 May 2022 18:29:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> src/java.base/share/classes/jdk/internal/util/StaticProperty.java line 251:
> 
>> 249: 
>> 250:     /**
>> 251:      * Return the {@code sun.jnu.encoding} system property.
> 
> This can be eliminated by changing the`@return` block tag below to `{@return the {@code sun.jnu.encoding} ...}`.

Hello @naotoj .
I appreciate your comment.
I'd like to confirm one thing.
I applied following change

    /**
     * {@return the {@code sun.jnu.encoding} system property}
     *
     * <strong>{@link SecurityManager#checkPropertyAccess} is NOT checked
     * in this method. The caller of this method should take care to ensure
     * that the returned property is not made accessible to untrusted code.</strong>
     */


By javadoc command with -html5 option, above part was converted to

Returns the sun.jnu.encoding system property. SecurityManager.checkPropertyAccess(java.lang.String) 
is NOT checked in this method. The caller of this method should take care to ensure that the returned 
property is not made accessible to untrusted code.

The 1st word changed from **Return** to **Returns**.
Is it OK ?
And it seems `@return` is translated to Japanese on Japanese environment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From darcy at openjdk.java.net  Mon May 16 17:29:16 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 16 May 2022 17:29:16 GMT
Subject: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses [v4]
In-Reply-To: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
References: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
Message-ID: <pIxbQeSSB1L3d3qzVbyIQl_FyzFc7u5AX5tZPB-6vSs=.cf7b2ff7-3775-40d3-a3a6-600b0eb81e5b@github.com>

> Make the javadoc in the InputStream and OutputStream subclasses in core libs DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in client libs will be done another a separate bug.) When the time comes, will do any necessary merging for the changes in[JDK-8286200.
> 
> Please also review the CSR to cover the introduction of implspec and implNote tags: https://bugs.openjdk.java.net/browse/JDK-8286784

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add @Override's requested in review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8717/files
  - new: https://git.openjdk.java.net/jdk/pull/8717/files/07e8a6a6..c31a408d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8717&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8717&range=02-03

  Stats: 11 lines in 5 files changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8717.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8717/head:pull/8717

PR: https://git.openjdk.java.net/jdk/pull/8717

From jvernee at openjdk.java.net  Mon May 16 17:40:41 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 16 May 2022 17:40:41 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
Message-ID: <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>

> Hi,
> 
> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
> 
> Thanks,
> Jorn
> 
> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  BootstrapMethodError -> ExceptionInInitializerError

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8685/files
  - new: https://git.openjdk.java.net/jdk/pull/8685/files/80640bac..cd3daab5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8685.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8685/head:pull/8685

PR: https://git.openjdk.java.net/jdk/pull/8685

From jvernee at openjdk.java.net  Mon May 16 17:40:42 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 16 May 2022 17:40:42 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <_vOeEJsQJfMPt3ECcI2OKwrFBS4WPRqJA8O6YtFkiI4=.f5285c7b-cf85-4f6e-a206-1262ee29bec2@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <_vOeEJsQJfMPt3ECcI2OKwrFBS4WPRqJA8O6YtFkiI4=.f5285c7b-cf85-4f6e-a206-1262ee29bec2@github.com>
Message-ID: <Mu8HIoWw-iUG6zzG12byA7onmRiRA8aZBkhVVc4ZbzQ=.0d531421-19ab-45d9-83dd-51938ef28395@github.com>

On Thu, 12 May 2022 18:15:54 GMT, liach <duke at openjdk.java.net> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootstrapMethodError -> ExceptionInInitializerError
>
> test/micro/org/openjdk/bench/java/lang/foreign/LinkUpcall.java line 61:
> 
>> 59:             BLANK = lookup().findStatic(LinkUpcall.class, "blank", MethodType.methodType(void.class));
>> 60:         } catch (ReflectiveOperationException e) {
>> 61:             throw new BootstrapMethodError(e);
> 
> You probably mean exception in initializer error.

Change it to ExceptionInInitializerError

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From naoto at openjdk.java.net  Mon May 16 17:55:38 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 16 May 2022 17:55:38 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v8]
In-Reply-To: <fMVjXcsuYYBThCM0SuFmCHaOVcSWlOftrjAzm-4hFek=.ba7676b8-a6da-4439-8757-d9c9592cd473@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <L1PK61h3l9Oykbzpg0UXFu8v1cA2pJqjxaxs-zFHW60=.75aad5fe-1814-4b1f-8660-68afe1928e63@github.com>
 <9uYukMkKKeD4KCdJamFXCQ3izhcDC2XBqV-QknU9Z1Y=.84a824f8-e319-4af1-9c92-c5fc2bc4565c@github.com>
 <fMVjXcsuYYBThCM0SuFmCHaOVcSWlOftrjAzm-4hFek=.ba7676b8-a6da-4439-8757-d9c9592cd473@github.com>
Message-ID: <hwn5-bPhosX-zOj5we_wrI4qXrc_0uVSWMO3cVZuvKg=.551f2884-9fd0-48ce-aac3-3803f11e83d7@github.com>

On Mon, 16 May 2022 17:16:31 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> The 1st word changed from Return to Returns.
Is it OK ?

That's more of plain English to me. Maybe some natives can correct it if needed.

> And it seems @return is translated to Japanese on Japanese environment.

Yes. I believe that's what is supposed to work.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From alanb at openjdk.java.net  Mon May 16 17:56:41 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 16 May 2022 17:56:41 GMT
Subject: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses [v4]
In-Reply-To: <pIxbQeSSB1L3d3qzVbyIQl_FyzFc7u5AX5tZPB-6vSs=.cf7b2ff7-3775-40d3-a3a6-600b0eb81e5b@github.com>
References: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
 <pIxbQeSSB1L3d3qzVbyIQl_FyzFc7u5AX5tZPB-6vSs=.cf7b2ff7-3775-40d3-a3a6-600b0eb81e5b@github.com>
Message-ID: <QS4LeW9gDmPJXmgOT5Zbe2Otbh4jtOClR5OpiSjWb9k=.93ebb6cf-f525-4238-b837-dc1b266a1941@github.com>

On Mon, 16 May 2022 17:29:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Make the javadoc in the InputStream and OutputStream subclasses in core libs DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in client libs will be done another a separate bug.) When the time comes, will do any necessary merging for the changes in[JDK-8286200.
>> 
>> Please also review the CSR to cover the introduction of implspec and implNote tags: https://bugs.openjdk.java.net/browse/JDK-8286784
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @Override's requested in review feedback.

thanks for the updates.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8717

From joehw at openjdk.java.net  Mon May 16 18:19:35 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 16 May 2022 18:19:35 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <IrEGv8YNAW0EZP5OYpMsxrrGQP_os0ADgHGG7UN8se0=.539d0ff4-e63c-4cb3-ade2-0e1478becc9a@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
 <IrEGv8YNAW0EZP5OYpMsxrrGQP_os0ADgHGG7UN8se0=.539d0ff4-e63c-4cb3-ade2-0e1478becc9a@github.com>
Message-ID: <5GhqxUu8sjpl82TMfU0Ak9EaSO1c1zK3BjDZEhdIZU4=.d80b7da8-0223-46da-bcf4-ce2b74a12b1a@github.com>

On Mon, 16 May 2022 16:35:16 GMT, Shruthi <duke at openjdk.java.net> wrote:

> `/integrate`

There may be sth. with your input, it's not recognized as Git command. Try again, or copy this command instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From naoto at openjdk.java.net  Mon May 16 18:26:33 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 16 May 2022 18:26:33 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
Message-ID: <aMfswvEA0EQnTfacmC1VnUj5SwHvp3MCbLvinbYhSEM=.a8580a46-d246-4eef-a1f3-d7ea89b8a02e@github.com>

On Thu, 12 May 2022 18:02:26 GMT, Shruthi <duke at openjdk.java.net> wrote:

>> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
>> 
>> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097
>
> Shruthi 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:
> 
>   Modify copyright year

Do not enclose the skara command within backquotes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From joehw at openjdk.java.net  Mon May 16 18:30:38 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 16 May 2022 18:30:38 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <aMfswvEA0EQnTfacmC1VnUj5SwHvp3MCbLvinbYhSEM=.a8580a46-d246-4eef-a1f3-d7ea89b8a02e@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
 <aMfswvEA0EQnTfacmC1VnUj5SwHvp3MCbLvinbYhSEM=.a8580a46-d246-4eef-a1f3-d7ea89b8a02e@github.com>
Message-ID: <7WijoWduT9XKDeGodvpvNPHBAjeN5-SFW7nTf5Y9FBg=.5a1415e2-b3bb-4f4c-be86-41dbfb471169@github.com>

On Mon, 16 May 2022 18:23:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Do not enclose the skara command within backquotes.

Thanks Naoto!  I didn't realize that's what he did :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From mchung at openjdk.java.net  Mon May 16 18:58:36 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 16 May 2022 18:58:36 GMT
Subject: RFR: JDK-8281001 Examine the behavior of Class::forName if the
 caller is null
In-Reply-To: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
Message-ID: <l4dAZutgz4yucd8gLBaqi5fZuihA1ZoZckeoA3e1mjM=.e8c0380b-ba55-43d6-895f-7278c07f07ca@github.com>

On Sat, 14 May 2022 00:30:00 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.

`Class::forName(String)` javadoc should specify which class loader to use when invoked with null caller similar to the other APIs you fixed for null callers.

I think this new test case does not belong to `NullCallerGetResource.java` which is a test for `Module::getResource`.    It's better to be placed under the `test/jdk/java/lang/Class/forName` directory that makes it clear it's a test for `Class::forName`. 

Alternatively, we could move all the tests for null caller under a new clearly-named directory, maybe `test/jdk/jdk/nullCaller`.    This may allow to do some refactoring and remove the duplicated code in these test cases.   What do you think?

src/java.base/share/classes/java/lang/Class.java line 385:

> 383:         ClassLoader loader = (caller == null) ?
> 384:                 ClassLoader.getSystemClassLoader() :
> 385:                 ClassLoader.getClassLoader(caller);

Formatting nit:

   ClassLoader loader = (caller == null) ? ClassLoader.getSystemClassLoader()
                                         : ClassLoader.getClassLoader(caller);

test/jdk/java/lang/module/exeNullCallerGetResource/NullCallerGetResource.java line 28:

> 26:  * @test
> 27:  * @bug 8281006
> 28:  * @bug 8281001

Suggestion:

 * @bug 8281006 8281001


`@bug` can have one or more bug IDs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8711

From prr at openjdk.java.net  Mon May 16 19:25:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 16 May 2022 19:25:45 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
Message-ID: <a8Hn2ADIbVx_hJQBxNRAoOzzRq2alog_rffWTnhzjs0=.1f2a16b4-7157-4678-b2c4-5194278ec1eb@github.com>

On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change for java.c , parse_manifest.c , LinuxPackage.c

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From prr at openjdk.java.net  Mon May 16 19:25:45 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 16 May 2022 19:25:45 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2]
In-Reply-To: <PAHnhQmFdvqr4WpEEmWHOc2exFIeX6zxHCQQs72eJ50=.5430fb2e-e5a8-4fec-8f2b-ab47fd7caf51@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <jS74meayB_B7H2mcnG_QkEps_zILbIJtH4QMtLAYqek=.b69c2a57-16fc-439b-b6c6-a34114516b0d@github.com>
 <idUoB0Z36T0LaCH88exydYE6bg6AOpXv1iJQjk9xOZQ=.1ee7d5af-e34d-4442-ae03-55732b86f6cb@github.com>
 <K1rvr4pekoOqk0CX5AKpq3F61FANUJlquDwtmZ3BGbQ=.6a57b5dc-73ad-4206-b9d7-52c9e695b02f@github.com>
 <PAHnhQmFdvqr4WpEEmWHOc2exFIeX6zxHCQQs72eJ50=.5430fb2e-e5a8-4fec-8f2b-ab47fd7caf51@github.com>
Message-ID: <wXTFsizq8jwpILVWeEcot4TzOHaEEEAtE1B3xoCPJQg=.3c063b65-9497-4dcc-851e-ae813a1afd1e@github.com>

On Thu, 12 May 2022 00:26:41 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I don't understand what the actual warning is getting at .. can anyone explain it ?
>> 
>> FWIW the code is still the same in upstream harfbuzz
>> https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc
>
> I've pasted a part of warning messages to description of this PR, all of messages are here:
> 
> 
> In function 'void trampoline_reference(hb_trampoline_closure_t*)',
>     inlined from 'void hb_font_funcs_set_glyph_func(hb_font_funcs_t*, hb_font_get_glyph_func_t, void*, hb_destroy_func_t)' at /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2368:24:

So upstream say it is not a problem since the analysis overlooks that it would not reach that free if it were immutable because of a previous check. I guess we disable the false positive warning for now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From joehw at openjdk.java.net  Mon May 16 19:40:58 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 16 May 2022 19:40:58 GMT
Subject: RFR: 8282280: Update Xerces to Version 2.12.2
Message-ID: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>

Update to Xerces 2.12.2.

The update also fixes JDK-8144117. Added a test.

Tests: local XML tests passed. Tier2 running. Two JCK tests failed with this update. See related issue report.

-------------

Commit messages:
 - 8282280: Update Xerces to Version 2.12.2

Changes: https://git.openjdk.java.net/jdk/pull/8732/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8732&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282280
  Stats: 310 lines in 17 files changed: 296 ins; 3 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8732.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8732/head:pull/8732

PR: https://git.openjdk.java.net/jdk/pull/8732

From mcimadamore at openjdk.java.net  Mon May 16 20:56:26 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 16 May 2022 20:56:26 GMT
Subject: RFR: 8286715: Generalize MemorySegment::ofBuffer [v2]
In-Reply-To: <zeaLhFMyC1279aCYqNzyT23OI6AXiUxzkWNS68yJbQs=.55dd8eec-7f94-4897-9cab-2d4485ff05cc@github.com>
References: <zeaLhFMyC1279aCYqNzyT23OI6AXiUxzkWNS68yJbQs=.55dd8eec-7f94-4897-9cab-2d4485ff05cc@github.com>
Message-ID: <isfwCQWYU3oUkLuZ6ShtgR_Wydqs-jlIbjiuoUX70Wk=.c73a0738-1450-4f8d-bd38-3b6cc2069cc9@github.com>

> This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`.
> This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function.
> 
> We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`.
> So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`.
> 
> In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8701/files
  - new: https://git.openjdk.java.net/jdk/pull/8701/files/02494e2f..b6629787

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8701&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8701&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8701.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8701/head:pull/8701

PR: https://git.openjdk.java.net/jdk/pull/8701

From mcimadamore at openjdk.java.net  Mon May 16 20:59:41 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 16 May 2022 20:59:41 GMT
Subject: Integrated: 8286756: Cleanup foreign API benchmarks
In-Reply-To: <548L9IsOJxCm2fzP-G5IzPkTLsu9UXHM8MW1_Ereb-M=.af48c268-0144-4200-ae98-7fad29f23a3f@github.com>
References: <548L9IsOJxCm2fzP-G5IzPkTLsu9UXHM8MW1_Ereb-M=.af48c268-0144-4200-ae98-7fad29f23a3f@github.com>
Message-ID: <oxYEgpAbyEqqLDmRU4eukB6nH222eNU-BVYSfyrLCiI=.019dd55a-cdbe-4816-9484-8fe2e89a116c@github.com>

On Fri, 13 May 2022 15:48:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This simple patch regularizes some of the foreign API benchmarks. Some of the changes are:
> 
> * use of capital names for var handle and layout constants
> * move shared layout and var handle constants in a new superclass, `JavaLayouts`
> * regularize aligned vs. unaligned benchmarks, especially in `LoopOverNonConstantHeap`. Since the API now aligns layouts by default, where the benchmark name doesn't say anything we assume aligned layout; for benchmarks that test specifically the use of unaligned layouts, we use the `_unaligned` prefix.

This pull request has now been integrated.

Changeset: 40f4dabc
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/40f4dabce8f6f13cf1c78354a2a1f3d8d7887e19
Stats:     204 lines in 13 files changed: 54 ins; 69 del; 81 mod

8286756: Cleanup foreign API benchmarks

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.java.net/jdk/pull/8705

From lancea at openjdk.java.net  Mon May 16 21:14:32 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 16 May 2022 21:14:32 GMT
Subject: RFR: 8282280: Update Xerces to Version 2.12.2
In-Reply-To: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
References: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
Message-ID: <pnjS1MUDA7rn1msily7xNNlzJ6AzHD33Sa-3zcY3234=.716c6ecc-6aba-4e54-9ab1-7f7c05302be5@github.com>

On Mon, 16 May 2022 19:34:11 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Update to Xerces 2.12.2.
> 
> The update also fixes JDK-8144117. Added a test.
> 
> Tests: local XML tests passed. Tier2 running. Two JCK tests failed with this update. See related issue report.

Hi Joe,

I think  your changes are ok

Are you going to wait until the JCK is updated to either patch or exclude these tests?

It would be good to get the JCK addressed prior to pushing the changes

-------------

PR: https://git.openjdk.java.net/jdk/pull/8732

From joehw at openjdk.java.net  Mon May 16 21:24:36 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 16 May 2022 21:24:36 GMT
Subject: RFR: 8282280: Update Xerces to Version 2.12.2
In-Reply-To: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
References: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
Message-ID: <Y1BKwBR1K9NcqaObuSwhjPSKTLUHLRti3hIrmWc4c5E=.80c04572-6248-4681-a422-d2a3b4c4ee87@github.com>

On Mon, 16 May 2022 19:34:11 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Update to Xerces 2.12.2.
> 
> The update also fixes JDK-8144117. Added a test.
> 
> Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this update. See related issue report.

Thanks Lance.

Yes, I've notified the JCK team, will wait till they've resolved the issue (or at least put them in the known list). Meanwhile, just want to get the patch reviewed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8732

From bpb at openjdk.java.net  Mon May 16 21:38:02 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 16 May 2022 21:38:02 GMT
Subject: RFR: 8213045: Add commonly used symbolic math constants to the JDK
Message-ID: <KEY7pcoz01lL7ePNaD9N7HTqCsde-QBVqkY7c6oJ7xE=.6b0623a6-a452-4212-ba4e-b45061ec4f52@github.com>

Add constant `java.math.BigDecimal.TWO`.

-------------

Commit messages:
 - 8213045: Add commonly used symbolic math constants to the JDK

Changes: https://git.openjdk.java.net/jdk/pull/8735/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8735&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8213045
  Stats: 17 lines in 2 files changed: 12 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8735.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8735/head:pull/8735

PR: https://git.openjdk.java.net/jdk/pull/8735

From naoto at openjdk.java.net  Mon May 16 22:01:35 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 16 May 2022 22:01:35 GMT
Subject: RFR: 8282280: Update Xerces to Version 2.12.2
In-Reply-To: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
References: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
Message-ID: <G85ZcESVU2cb2UjuMQO7N6i1ns3nmhTWHmvNsmGAz1U=.a73eafaa-d938-423c-a6a5-287465df56c0@github.com>

On Mon, 16 May 2022 19:34:11 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Update to Xerces 2.12.2.
> 
> The update also fixes JDK-8144117. Added a test.
> 
> Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this update. See related issue report.

Changes look good to me. Some minor nits follow.

test/jaxp/javax/xml/jaxp/unittest/validation/SchemaTest.java line 48:

> 46:  */
> 47: public class SchemaTest {
> 48:     private static final String XSD_8144117 = "<?xml version='1.0'?>\n" +

If it is not from the upstream Xerces test but our own, can we utilize text blocks here?

test/jaxp/javax/xml/jaxp/unittest/validation/SchemaTest.java line 79:

> 77: 
> 78:     /*
> 79:      * DataProvider: valid xsd

This comment is the same as the above provider. Can we change it to a more meaningful one?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8732

From lmesnik at openjdk.java.net  Mon May 16 22:09:33 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Mon, 16 May 2022 22:09:33 GMT
Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to
 collect data due to permission issues [v2]
In-Reply-To: <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>
References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>
 <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>
Message-ID: <Lad0uTVFFkYOzwPEInNn8LuejoaI-JIYpJfYNg9_LcY=.833f8b19-3a27-4990-b3b6-b35506d67086@github.com>

On Fri, 13 May 2022 14:39:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS?
>> 
>> As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command.
>> 
>> Tested locally on macOS by running:
>> 
>> 
>> cd test/failure_handler
>> make clean
>> make test
>> 
>> Then checked the generated environment.html files for the dmesg command output. Looks fine after this change.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

Looks reasonable.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8703

From darcy at openjdk.java.net  Mon May 16 22:26:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 16 May 2022 22:26:40 GMT
Subject: RFR: 8213045: Add commonly used symbolic math constants to the JDK
In-Reply-To: <KEY7pcoz01lL7ePNaD9N7HTqCsde-QBVqkY7c6oJ7xE=.6b0623a6-a452-4212-ba4e-b45061ec4f52@github.com>
References: <KEY7pcoz01lL7ePNaD9N7HTqCsde-QBVqkY7c6oJ7xE=.6b0623a6-a452-4212-ba4e-b45061ec4f52@github.com>
Message-ID: <e0v28oEFC04tsi1U0qCvmRpqSy74NMweIVHlpdmaKfY=.47874b74-fb04-4ba0-8b6c-1388523c37ac@github.com>

On Mon, 16 May 2022 21:29:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add constant `java.math.BigDecimal.TWO`.

Looks fine.

-------------

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8735

From iklam at openjdk.java.net  Mon May 16 22:31:33 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 16 May 2022 22:31:33 GMT
Subject: RFR: JDK-8281001 Examine the behavior of Class::forName if the
 caller is null
In-Reply-To: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
Message-ID: <N6YyclK-Qf8vdd3aVHPbc4e8xcIhKd904s5CQhIfEdE=.5a7ada45-cf9f-4e3a-acf5-140ab3ca7a46@github.com>

On Sat, 14 May 2022 00:30:00 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.

Please rename the title of the issue to reflect what is being proposed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8711

From bpb at openjdk.java.net  Mon May 16 22:34:21 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 16 May 2022 22:34:21 GMT
Subject: RFR: 8213045: Add BigDecimal.TWO [v2]
In-Reply-To: <KEY7pcoz01lL7ePNaD9N7HTqCsde-QBVqkY7c6oJ7xE=.6b0623a6-a452-4212-ba4e-b45061ec4f52@github.com>
References: <KEY7pcoz01lL7ePNaD9N7HTqCsde-QBVqkY7c6oJ7xE=.6b0623a6-a452-4212-ba4e-b45061ec4f52@github.com>
Message-ID: <TvonkfJ6jVIUm6dDWwmsi2mDEV0WgoeGRGFTzUCfrR0=.3e627e2a-91d7-4d28-a67b-274e4f2cbc30@github.com>

> Add constant `java.math.BigDecimal.TWO`.

Brian Burkhalter 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:

  8213045: Add BigDecimal.TWO

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8735/files
  - new: https://git.openjdk.java.net/jdk/pull/8735/files/df4cf704..434bc3de

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8735&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8735&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8735.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8735/head:pull/8735

PR: https://git.openjdk.java.net/jdk/pull/8735

From jjg at openjdk.java.net  Mon May 16 22:34:37 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 16 May 2022 22:34:37 GMT
Subject: Withdrawn: JDK-8286347: incorrect use of `{@link}`
In-Reply-To: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
References: <4FIQ6yXtMxzQMITNy-RT-M20pcnGj064Seo12UvrjGg=.e7a1457d-7366-4bba-967e-6f156dd96dc8@github.com>
Message-ID: <v2xEydIY9L7qwqnyPi4-lgdt6iDfB-3Z35-R5rkmMOU=.bf50a824-a6ba-4c1c-aa2e-3e99de798dd6@github.com>

On Fri, 6 May 2022 23:30:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small doc fix to update incorrect use of `{@link}` on arrays of primitive types.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8584

From darcy at openjdk.java.net  Mon May 16 22:53:39 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 16 May 2022 22:53:39 GMT
Subject: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses [v4]
In-Reply-To: <QS4LeW9gDmPJXmgOT5Zbe2Otbh4jtOClR5OpiSjWb9k=.93ebb6cf-f525-4238-b837-dc1b266a1941@github.com>
References: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
 <pIxbQeSSB1L3d3qzVbyIQl_FyzFc7u5AX5tZPB-6vSs=.cf7b2ff7-3775-40d3-a3a6-600b0eb81e5b@github.com>
 <QS4LeW9gDmPJXmgOT5Zbe2Otbh4jtOClR5OpiSjWb9k=.93ebb6cf-f525-4238-b837-dc1b266a1941@github.com>
Message-ID: <XFeti1hhGsDEcMBwBiVxNZCrNdqVykYNk9DjFJeLw3U=.1f345422-76d8-4ebf-ba3e-539c3c114210@github.com>

On Mon, 16 May 2022 17:53:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> thanks for the updates.

Updated the CSR to match this version.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8717

From alexander.matveev at oracle.com  Tue May 17 00:09:59 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 17 May 2022 00:09:59 +0000
Subject: [External] : Re: RFR: 8286122: [macos]: App bundle cannot upload
 to Mac App Store due to info.plist embedded in java exe
In-Reply-To: <0441CF7A-8653-41E8-B084-A7F4863991D6@gmail.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
 <8C1C5A6D-6D14-48B0-8C5A-9D9EE18A78A0@oracle.com>
 <0441CF7A-8653-41E8-B084-A7F4863991D6@gmail.com>
Message-ID: <0035A912-1C97-4F9A-8598-5EAD12188CEC@oracle.com>

Hi Michael,

> 
>>> 
>>> I?m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?
>> Yes, it should be possible and in theory such JDK with native commands can be used. However, current fix will not allow such JDK build, since we checking for presence of ?bin? folder and not if ID is actually unique. To work around this limitation user can package without native commands first, then add native commands and re-sign application.
> 
> Signing is currently an integrated part of the process. I thought about making an enhancement request to have it possible to do it stepped. First build the application, then allow the user to post-process that. Maybe run a tool/script to modify the application level Info.plist file. Then allow a second final step that does the signing. I don?t remember if I actually made that enhancement request. But currently there is no way with jpackage to standalone sign the application is there? I think this is somewhat involved with the application bundle being iterated and for one thing each jar being separately code signed? I think it took a release or two of the command to get this correct. So I doubt Xcode could manage it. Is there a way to do the signing standalone with jpackage that I am not aware of?
> 
> If I didn?t do an enhancement request on this I could, if you think jpackage could manage it?
> 

There is no a way to do the signing of standalone app image and app image will not get signed if you generating DMG or PKG by providing app image via ?app-image and specifing signing. Only PKG will get signed if signing is specified with ?app-image.

Currently jpackage will block following command:
jpackage --type app-image --app-image Test.app --mac-sign ...
Error: Option [--app-image] is not valid with type [app-image]

I think we can allow app-image type with app image input if signing is requested and command from above will just sign app image in place.

Generating DMG or PKG from ?app-image and with signing enabled will not sign app image as it currently do.

If no objections for proposed enhancement I will go ahead and file one.

Thanks,
Alexander

From jpai at openjdk.java.net  Tue May 17 00:13:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 17 May 2022 00:13:46 GMT
Subject: RFR: 8286744: failure_handler: dmesg command on macos fails to
 collect data due to permission issues [v2]
In-Reply-To: <Lad0uTVFFkYOzwPEInNn8LuejoaI-JIYpJfYNg9_LcY=.833f8b19-3a27-4990-b3b6-b35506d67086@github.com>
References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>
 <1-Ldb8IT_mYRcJ0D7OXf8Z7_p3RVqVNcYffYcdeZBsU=.b1bfb202-ea37-42f1-9f2e-f69644cdeb2a@github.com>
 <Lad0uTVFFkYOzwPEInNn8LuejoaI-JIYpJfYNg9_LcY=.833f8b19-3a27-4990-b3b6-b35506d67086@github.com>
Message-ID: <h3NuF3Ws1SFxsWqS0fzTsbczhjAtDvc2UGhyOrA3z6g=.201c4e43-20be-4a17-aa9b-6ad49c14d94d@github.com>

On Mon, 16 May 2022 22:06:25 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyright year
>
> Looks reasonable.

Thank you @lmesnik  for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8703

From jpai at openjdk.java.net  Tue May 17 00:13:47 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 17 May 2022 00:13:47 GMT
Subject: Integrated: 8286744: failure_handler: dmesg command on macos fails to
 collect data due to permission issues
In-Reply-To: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>
References: <51zgUpu3hsNecf8zocdpEbBrwy9qZ63oSRSfK287vDI=.2756a33a-05aa-4458-a23a-9344ac0f6ae5@github.com>
Message-ID: <mONby4FoQ8lp8qk3xVrpL_J79hp8SlE2Tuv0IbpzZzY=.293fb9d3-6f81-4ccd-984d-d12be0bbf1c2@github.com>

On Fri, 13 May 2022 14:17:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the failure handler command `dmesg` on macOS?
> 
> As noted in the JBS issue, the command currently fails with permission error. The commit in this PR uses `sudo` as suggested in the man pages of that command.
> 
> Tested locally on macOS by running:
> 
> 
> cd test/failure_handler
> make clean
> make test
> 
> Then checked the generated environment.html files for the dmesg command output. Looks fine after this change.

This pull request has now been integrated.

Changeset: 125efe6c
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/125efe6cbaf1e2c263d74a4ada395ac30c479faa
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8286744: failure_handler: dmesg command on macos fails to collect data due to permission issues

Reviewed-by: dfuchs, lancea, lmesnik

-------------

PR: https://git.openjdk.java.net/jdk/pull/8703

From joehw at openjdk.java.net  Tue May 17 00:39:37 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 17 May 2022 00:39:37 GMT
Subject: RFR: 8282280: Update Xerces to Version 2.12.2 [v2]
In-Reply-To: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
References: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
Message-ID: <3y07XSVou7GU8asGFL6HZ99bhd-i87hMAOBD3yDdusQ=.336f474c-5317-4bcd-8ac2-281d7f30c2a4@github.com>

> Update to Xerces 2.12.2.
> 
> The update also fixes JDK-8144117. Added a test.
> 
> Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this update. See related issue report.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  provider description

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8732/files
  - new: https://git.openjdk.java.net/jdk/pull/8732/files/ae224c6d..db91b60e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8732&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8732&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8732.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8732/head:pull/8732

PR: https://git.openjdk.java.net/jdk/pull/8732

From joehw at openjdk.java.net  Tue May 17 00:39:38 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 17 May 2022 00:39:38 GMT
Subject: RFR: 8282280: Update Xerces to Version 2.12.2 [v2]
In-Reply-To: <G85ZcESVU2cb2UjuMQO7N6i1ns3nmhTWHmvNsmGAz1U=.a73eafaa-d938-423c-a6a5-287465df56c0@github.com>
References: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
 <G85ZcESVU2cb2UjuMQO7N6i1ns3nmhTWHmvNsmGAz1U=.a73eafaa-d938-423c-a6a5-287465df56c0@github.com>
Message-ID: <D0ayHyZQXaU1omCQG8erpTL5n6zpJ_OVTFkylIgFnOA=.ee3fc437-4571-40e2-8435-7748b80905ea@github.com>

On Mon, 16 May 2022 21:54:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   provider description
>
> test/jaxp/javax/xml/jaxp/unittest/validation/SchemaTest.java line 48:
> 
>> 46:  */
>> 47: public class SchemaTest {
>> 48:     private static final String XSD_8144117 = "<?xml version='1.0'?>\n" +
> 
> If it is not from the upstream Xerces test but our own, can we utilize text blocks here?

Our source level is still generally 8. The expectation is also that this patch will be backported.

> test/jaxp/javax/xml/jaxp/unittest/validation/SchemaTest.java line 79:
> 
>> 77: 
>> 78:     /*
>> 79:      * DataProvider: valid xsd
> 
> This comment is the same as the above provider. Can we change it to a more meaningful one?

Updated with a bit more description.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8732

From mik3hall at gmail.com  Tue May 17 01:03:57 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 16 May 2022 20:03:57 -0500
Subject: [External] : Re: RFR: 8286122: [macos]: App bundle cannot upload
 to Mac App Store due to info.plist embedded in java exe
In-Reply-To: <0035A912-1C97-4F9A-8598-5EAD12188CEC@oracle.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
 <8C1C5A6D-6D14-48B0-8C5A-9D9EE18A78A0@oracle.com>
 <0441CF7A-8653-41E8-B084-A7F4863991D6@gmail.com>
 <0035A912-1C97-4F9A-8598-5EAD12188CEC@oracle.com>
Message-ID: <DD9D156D-7F46-45A1-9A3E-8FB03B130CE9@gmail.com>



> On May 16, 2022, at 7:09 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
>> 
>>>> 
>>>> I?m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?
>>> Yes, it should be possible and in theory such JDK with native commands can be used. However, current fix will not allow such JDK build, since we checking for presence of ?bin? folder and not if ID is actually unique. To work around this limitation user can package without native commands first, then add native commands and re-sign application.
>> 
>> Signing is currently an integrated part of the process. I thought about making an enhancement request to have it possible to do it stepped. First build the application, then allow the user to post-process that. Maybe run a tool/script to modify the application level Info.plist file. Then allow a second final step that does the signing. I don?t remember if I actually made that enhancement request. But currently there is no way with jpackage to standalone sign the application is there? I think this is somewhat involved with the application bundle being iterated and for one thing each jar being separately code signed? I think it took a release or two of the command to get this correct. So I doubt Xcode could manage it. Is there a way to do the signing standalone with jpackage that I am not aware of?
>> 
>> If I didn?t do an enhancement request on this I could, if you think jpackage could manage it?
>> 
> 
> There is no a way to do the signing of standalone app image and app image will not get signed if you generating DMG or PKG by providing app image via ?app-image and specifing signing. Only PKG will get signed if signing is specified with ?app-image.
> 
> Currently jpackage will block following command:
> jpackage --type app-image --app-image Test.app --mac-sign ...
> Error: Option [--app-image] is not valid with type [app-image]
> 
> I think we can allow app-image type with app image input if signing is requested and command from above will just sign app image in place.
> 
> Generating DMG or PKG from ?app-image and with signing enabled will not sign app image as it currently do.
> 
> If no objections for proposed enhancement I will go ahead and file one.
> 
> Thanks,
> Alexander

Alexander

I?m not entirely sure I?m following this. I assumed it wasn?t currently possible to do standalone signing against an application bundle but would require an enhancement request. If you are saying you will do that request yourself, that?s fine.
Again, I think this should be possible as a two step process. The first would be to generate the application bundle. Then perform some application bundle post-processing, probably independent of jpackage. Finally allow a jpackage invocation that takes the path to the completed application bundle and performs the signing. 
If this is what you are thinking we are on the same page. 

Thanks
Mike


From itakiguchi at openjdk.java.net  Tue May 17 01:19:30 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 17 May 2022 01:19:30 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v9]
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <gW6MccDl1j5z1UTgET1Ea8MTnZCKcoMKjcG33LkKzTQ=.de8ad983-825f-4090-9c7e-1d369d289488@github.com>

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8378/files
  - new: https://git.openjdk.java.net/jdk/pull/8378/files/12018014..b940a0d6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8378&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8378&range=07-08

  Stats: 43 lines in 1 file changed: 0 ins; 28 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8378.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8378/head:pull/8378

PR: https://git.openjdk.java.net/jdk/pull/8378

From itakiguchi at openjdk.java.net  Tue May 17 01:22:45 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Tue, 17 May 2022 01:22:45 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v9]
In-Reply-To: <0oFVCJWhQrze7dIhCE5j3VfKkWW-XkW40UduBmB_KiE=.2c75dc1b-415a-4e41-bb9f-5e32dfd7f470@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <0oFVCJWhQrze7dIhCE5j3VfKkWW-XkW40UduBmB_KiE=.2c75dc1b-415a-4e41-bb9f-5e32dfd7f470@github.com>
Message-ID: <h1VC6KB6gdL-fNNO84xWzq_Kb7qidH7MbqUchQxctGY=.e629236e-2097-412c-b8f6-4bb6d6b4653a@github.com>

On Tue, 26 Apr 2022 21:17:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> Thanks for fixing the issue.
> As to the test, it has lots of redundancy, and too complicated to me. Can you simplify the test?

Hello @naotoj .
To keep consistency, I modified other javadoc texts on `StaticProperty.java`.
And fix javdoc tag error.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From ysuenaga at openjdk.java.net  Tue May 17 01:24:49 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 01:24:49 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher
In-Reply-To: <EqpBY4VoH-sAMZTzPc2VsSFs51Tp0ti50UaPwORgqPE=.b7f8f052-cf24-44fb-b5b4-9c851942cb25@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
 <EqpBY4VoH-sAMZTzPc2VsSFs51Tp0ti50UaPwORgqPE=.b7f8f052-cf24-44fb-b5b4-9c851942cb25@github.com>
Message-ID: <D-seUwimZ5QV4nF77umHk_dUGyVDXP7LVnBofYZKLL4=.6f98d277-40ce-44bf-a2bc-316284ea46f0@github.com>

On Mon, 16 May 2022 13:20:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> GCC 12 reports as following:
>
> I don't recall what "builtin arguments" means. Can you tell me how we would actually hit this conditions such that we string dup and  the null string? Or are you saying this is actually an unreachable case: the check for NULL is always false and the actual  string is never null anyway?

@dholmes-ora 
As I wrote in the description, `jargv` comes from `JAVA_ARGS` or `EXTRA_JAVA_ARGS` - end user cannot modify them. So I think they should be reported as developer error.
OTOH JDK developer cannot know invalid options if they do not set trace mode to launcher. So I want to discuss how we should handle invalid parameter(s) in `jargv`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From ysuenaga at openjdk.java.net  Tue May 17 01:28:49 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 01:28:49 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4]
In-Reply-To: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <hRz0_TToYgAPiC2722w2E0YzZztTp34v74R4OM6A78k=.f5ae0319-cd63-421a-b416-652757587567@github.com>
 <cbS0XWcBC0vi8SjU3V3dS4feDWBnMbPjSyCXqoPGcb4=.f2cdf49d-0915-46b1-b436-e3699e94892c@github.com>
 <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com>
Message-ID: <B8cPPY4k-xmy3JAJ8MH4yIwDB2U3NAkKr2gtCPEqIcw=.3a6c3953-eefb-485f-8e98-8f1e50f1c12c@github.com>

On Thu, 12 May 2022 11:02:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Thanks for all to review this PR! I think we should separate this issue as following:
>> 
>> * Suppress warnings
>>     * make/modules/java.desktop/lib/Awt2dLibraries.gmk
>>     * src/hotspot/share/classfile/bytecodeAssembler.cpp
>>     * src/hotspot/share/classfile/classFileParser.cpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>>     * src/hotspot/share/opto/memnode.cpp
>>     * src/hotspot/share/opto/type.cpp
>>     * src/hotspot/share/utilities/compilerWarnings.hpp
>>     * src/hotspot/share/utilities/compilerWarnings_gcc.hpp
>>     * src/java.base/unix/native/libjli/java_md_common.c
>> * Bug fixes
>>     * src/java.base/share/native/libjli/java.c
>>     * src/java.base/share/native/libjli/parse_manifest.c
>>     * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c
>> 
>> I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library.
>> 
>> I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only.
>
> @YaSuenag From my PoV this sounds like a good suggestion.

@magicus @prrace Thanks for your review!

Can I get the review from HotSpot folks? @kimbarrett

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From njian at openjdk.java.net  Tue May 17 02:07:39 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Tue, 17 May 2022 02:07:39 GMT
Subject: RFR: 8281712: [REDO] AArch64: Implement string_compare intrinsic
 in SVE
In-Reply-To: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>
References: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>
Message-ID: <Yo4aUICw9FslOR4GoUaC4ClwZi_p2Rt3zaCerZ5VOBs=.ee6dac37-200f-45a2-bd20-63f688dab45c@github.com>

On Mon, 16 May 2022 07:21:27 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> This is the REDO of JDK-8269559 and JDK-8275448. Those two backouts finally turned to be some system zlib issue in AArch64 macOS, and is not related to the patch itself. See [1][2] for details.
> 
> This patch is generally the same as JDK-8275448, which uses SVE to optimize string_compare intrinsics for long string comparisons. I did a rebase with small tweaks to get better performance on recent Neoverse hardware. Test data on systems with different SVE vector sizes:
> 
> 
>    case    delta size  128-bits  256-bits  512-bits
> compareToLL  2   24     0.17%     0.58%     0.00%
> compareToLL  2   36     0.00%    2.25%      0.04%
> compareToLL  2   72     -4.40%   3.87%      -12.82%
> compareToLL  2   128    4.55%    58.31%     13.53%
> compareToLL  2   256    19.39%   69.77%     82.03%
> compareToLL  2   512    1.81%    68.38%     170.93%
> compareToLU  2   24     25.57%   46.98%     54.61%
> compareToLU  2   36     36.03%   70.26%     94.33%
> compareToLU  2   72     35.86%   90.58%     146.04%
> compareToLU  2   128    70.82%   119.19%    266.22%
> compareToLU  2   256    80.77%   146.33%    420.01%
> compareToLU  2   512    94.62%   171.72%    530.87%
> compareToUL  2   24     20.82%   34.48%     62.14%
> compareToUL  2   36     39.77%   60.79%     69.77%
> compareToUL  2   72     35.46%   84.34%     121.90%
> compareToUL  2   128    67.77%   110.97%    220.53%
> compareToUL  2   256    77.05%   160.29%    331.30%
> compareToUL  2   512    91.88%   184.57%    524.21%
> compareToUU  2   24     -0.13%   0.40%      0.00%
> compareToUU  2   36     -9.18%   12.84%     -13.93%
> compareToUU  2   72     1.67%    60.61%     6.69%
> compareToUU  2   128    13.51%   60.33%     55.27%
> compareToUU  2   256    2.55%    62.17%     153.26%
> compareToUU  2   512    4.12%    68.62%     201.68%
> 
> JTreg tests passed on SVE hardware.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8275448
> [2] https://bugs.openjdk.java.net/browse/JDK-8282954

@TobiHartmann Could you please help to test this patch in Oracle test system? Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8723

From kbarrett at openjdk.java.net  Tue May 17 02:20:56 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 17 May 2022 02:20:56 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4]
In-Reply-To: <FhmdALeuSc3nk12GIb6HDLsugYmiWDHzlzn_5Zmuoq8=.46d91385-b9e6-49f6-bd41-6e00f46b8115@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <hRz0_TToYgAPiC2722w2E0YzZztTp34v74R4OM6A78k=.f5ae0319-cd63-421a-b416-652757587567@github.com>
 <cbS0XWcBC0vi8SjU3V3dS4feDWBnMbPjSyCXqoPGcb4=.f2cdf49d-0915-46b1-b436-e3699e94892c@github.com>
 <FhmdALeuSc3nk12GIb6HDLsugYmiWDHzlzn_5Zmuoq8=.46d91385-b9e6-49f6-bd41-6e00f46b8115@github.com>
Message-ID: <nfH4DMjomMYItuifW1kbRJS16-C7hMSCKiHyjjoauFw=.822ea233-0cea-40c2-a301-2e32de47e5c6@github.com>

On Thu, 12 May 2022 18:28:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thanks for all to review this PR! I think we should separate this issue as following:
>> 
>> * Suppress warnings
>>     * make/modules/java.desktop/lib/Awt2dLibraries.gmk
>>     * src/hotspot/share/classfile/bytecodeAssembler.cpp
>>     * src/hotspot/share/classfile/classFileParser.cpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>>     * src/hotspot/share/opto/memnode.cpp
>>     * src/hotspot/share/opto/type.cpp
>>     * src/hotspot/share/utilities/compilerWarnings.hpp
>>     * src/hotspot/share/utilities/compilerWarnings_gcc.hpp
>>     * src/java.base/unix/native/libjli/java_md_common.c
>> * Bug fixes
>>     * src/java.base/share/native/libjli/java.c
>>     * src/java.base/share/native/libjli/parse_manifest.c
>>     * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c
>> 
>> I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library.
>> 
>> I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only.
>
>> @YaSuenag From my PoV this sounds like a good suggestion.
> 
> +1

> Can I get the review from HotSpot folks? @kimbarrett

Already working on it.  There are some I don't understand yet.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From kbarrett at openjdk.java.net  Tue May 17 03:19:55 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 17 May 2022 03:19:55 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
Message-ID: <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>

On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change for java.c , parse_manifest.c , LinuxPackage.c

Some suggestions for code changes instead of warning suppression.  And some warnings that I don't yet understand and don't think should be suppressed without more details or investigation.

src/hotspot/share/classfile/bytecodeAssembler.cpp line 95:

> 93:         ShouldNotReachHere();
> 94:     }
> 95: PRAGMA_DIAG_POP

One of these is another of the symbol_at_put cases that I don't understand.  Are there other cases in the switch that warn?  And if so, which ones and how?  There are no details of this one in the PR cover description.

src/hotspot/share/classfile/classFileParser.cpp line 5970:

> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED
> 5969:   _cp->symbol_at_put(hidden_index, _class_name);
> 5970: PRAGMA_DIAG_POP

I don't understand these warning suppressions for symbol_at_put (here and elsewhere).  I don't see any stringops here.  What is the compiler complaining about?  (There's no mention of classfile stuff in the review cover message.)

src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103:

> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED
> 102:   *dest = op(bits, *dest);
> 103: PRAGMA_DIAG_POP

I see no stringop here.  I'm still trying to understand what the compiler is complaining about.

src/hotspot/share/opto/memnode.cpp line 1413:

> 1411:                    bt == T_BYTE    || bt == T_SHORT ||
> 1412:                    bt == T_INT     || bt == T_LONG, "wrong type = %s", type2name(bt));
> 1413: PRAGMA_DIAG_POP

The problem here is the definition of type2name, which returns NULL for an unknown BasicType.  It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source.

src/hotspot/share/opto/type.cpp line 4300:

> 4298: PRAGMA_FORMAT_OVERFLOW_IGNORED
> 4299:       fatal("not an element type: %s", type2name(etype));
> 4300: PRAGMA_DIAG_POP

Another occurrence of type2name returning NULL for unknown BasicType.

-------------

Changes requested by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8646

From dholmes at openjdk.java.net  Tue May 17 04:42:38 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 17 May 2022 04:42:38 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher
In-Reply-To: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
Message-ID: <yqxakAeLdUFdD1b3j4KiYqrZQOFp1Rm5qUxdBnsdDKs=.83a764c8-3664-4bba-a196-41070afd7fd8@github.com>

On Fri, 13 May 2022 08:56:59 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> GCC 12 reports as following:

You forced me to look at this in depth. The values are set via the build system. In the build system it is impossible to get just -J because the -J is only added as a prefix for an existing string. So basically this is impossible code to reach unless you manually override the build system definition. So as far as I can see this is a classic case where we want an assert.


if (arg[0] == '-' && arg[1] == 'J') {
    assert(arg[2] != '\0', "Invalid JAVA_ARGS or EXTRA_JAVA_ARGS defined by build");
    *nargv++ = JLI_StringDup(arg + 2);
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From duke at openjdk.java.net  Tue May 17 04:47:59 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 17 May 2022 04:47:59 GMT
Subject: RFR: 8286849: Use @Stable for generic repositories
Message-ID: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>

Generic repositories, the implementation detail for generic information in core reflection, can be updated to use the `@Stable` annotation to replace their `volatile` access. Their existing accessor code is already safe, reading the cache fields only once.

In addition, fixed potentially non-thread-safe `genericInfo` access in `Method`, `Field`, and `RecordComponent`.

-------------

Commit messages:
 - 8286849: Use @Stable for generic repositories

Changes: https://git.openjdk.java.net/jdk/pull/8742/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8742&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286849
  Stats: 45 lines in 11 files changed: 29 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8742.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8742/head:pull/8742

PR: https://git.openjdk.java.net/jdk/pull/8742

From kbarrett at openjdk.java.net  Tue May 17 04:56:00 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 17 May 2022 04:56:00 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
Message-ID: <njyWT3_tTXhWhjVC2ORdNf3PESMANtf0H2eDg9ColEw=.6347983e-51b8-428c-93ab-522ed23afba2@github.com>

On Tue, 17 May 2022 03:05:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change for java.c , parse_manifest.c , LinuxPackage.c
>
> src/hotspot/share/opto/memnode.cpp line 1413:
> 
>> 1411:                    bt == T_BYTE    || bt == T_SHORT ||
>> 1412:                    bt == T_INT     || bt == T_LONG, "wrong type = %s", type2name(bt));
>> 1413: PRAGMA_DIAG_POP
> 
> The problem here is the definition of type2name, which returns NULL for an unknown BasicType.  It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source.

While looking at type2name, I noticed the comment for the immediately preceding type2name_tab is wrong.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From alexander.matveev at oracle.com  Tue May 17 05:15:45 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Tue, 17 May 2022 05:15:45 +0000
Subject: [External] : Re: RFR: 8286122: [macos]: App bundle cannot upload
 to Mac App Store due to info.plist embedded in java exe
In-Reply-To: <DD9D156D-7F46-45A1-9A3E-8FB03B130CE9@gmail.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
 <8C1C5A6D-6D14-48B0-8C5A-9D9EE18A78A0@oracle.com>
 <0441CF7A-8653-41E8-B084-A7F4863991D6@gmail.com>
 <0035A912-1C97-4F9A-8598-5EAD12188CEC@oracle.com>
 <DD9D156D-7F46-45A1-9A3E-8FB03B130CE9@gmail.com>
Message-ID: <72E816AA-5F0B-4B58-BA06-9D10F03B37FE@oracle.com>

Hi Michael,

I filed following enhancement for signing user provided app image and yes it will be two step process. Invoke jpackage to generate image, then user can modified it and then invoke jpackage again to sign it.
https://bugs.openjdk.java.net/browse/JDK-8286850

For JDK-8286122, I will integrate proposed fix as is. Error will be thrown if user tries to include native commands for Mac App Store image.

Still not sure if we will provide solution for including native commands with Mac App Store. Including special versions of native commands with jpackage will work only if runtime is generated by jpackage. It will not solve issue with user provided runtime. Also, it is not clear if app updates will require same unique ID based on UUID across app versions.

Also, many functionality provided by native JDK commands can be used via ToolProvider. For example if you include jdk.jpackage module with your app, you should able to use jpackage functionality from your app via ToolProvider without actual jpackage native command.

Thanks,
Alexander

> On May 16, 2022, at 6:03 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On May 16, 2022, at 7:09 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
>> 
>> Hi Michael,
>> 
>>> 
>>>>> 
>>>>> I?m not real familiar with the build process. But would it be possible for the user to build their own jdk that substitutes something else for the colliding identifier that gets embedded?
>>>> Yes, it should be possible and in theory such JDK with native commands can be used. However, current fix will not allow such JDK build, since we checking for presence of ?bin? folder and not if ID is actually unique. To work around this limitation user can package without native commands first, then add native commands and re-sign application.
>>> 
>>> Signing is currently an integrated part of the process. I thought about making an enhancement request to have it possible to do it stepped. First build the application, then allow the user to post-process that. Maybe run a tool/script to modify the application level Info.plist file. Then allow a second final step that does the signing. I don?t remember if I actually made that enhancement request. But currently there is no way with jpackage to standalone sign the application is there? I think this is somewhat involved with the application bundle being iterated and for one thing each jar being separately code signed? I think it took a release or two of the command to get this correct. So I doubt Xcode could manage it. Is there a way to do the signing standalone with jpackage that I am not aware of?
>>> 
>>> If I didn?t do an enhancement request on this I could, if you think jpackage could manage it?
>>> 
>> 
>> There is no a way to do the signing of standalone app image and app image will not get signed if you generating DMG or PKG by providing app image via ?app-image and specifing signing. Only PKG will get signed if signing is specified with ?app-image.
>> 
>> Currently jpackage will block following command:
>> jpackage --type app-image --app-image Test.app --mac-sign ...
>> Error: Option [--app-image] is not valid with type [app-image]
>> 
>> I think we can allow app-image type with app image input if signing is requested and command from above will just sign app image in place.
>> 
>> Generating DMG or PKG from ?app-image and with signing enabled will not sign app image as it currently do.
>> 
>> If no objections for proposed enhancement I will go ahead and file one.
>> 
>> Thanks,
>> Alexander
> 
> Alexander
> 
> I?m not entirely sure I?m following this. I assumed it wasn?t currently possible to do standalone signing against an application bundle but would require an enhancement request. If you are saying you will do that request yourself, that?s fine.
> Again, I think this should be possible as a two step process. The first would be to generate the application bundle. Then perform some application bundle post-processing, probably independent of jpackage. Finally allow a jpackage invocation that takes the path to the completed application bundle and performs the signing. 
> If this is what you are thinking we are on the same page. 
> 
> Thanks
> Mike
> 


From forax at openjdk.java.net  Tue May 17 05:57:57 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 17 May 2022 05:57:57 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
Message-ID: <mRYW8NaJBMpGHqfTLW81a-rz5b8RRskduLrjUEuYGec=.ae5beab6-233b-4825-9ccb-78ad21aa9199@github.com>

On Mon, 16 May 2022 17:40:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BootstrapMethodError -> ExceptionInInitializerError

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 98:

> 96:     private static final String CLASS_DATA_DESC = methodType(Object.class, MethodHandles.Lookup.class, String.class, Class.class).descriptorString();
> 97:     private static final String RELEASE0_DESC = methodType(void.class).descriptorString();
> 98:     private static final String ACQUIRE0_DESC = methodType(void.class).descriptorString();

calling methodType() is quite slow because of the cache of MethodType so maybe those initialization should be done explicitly in a static block to avoid to recompute methodType(long).descriptorString() several times

src/java.base/share/classes/jdk/internal/foreign/abi/SoftReferenceCache.java line 42:

> 40: 
> 41:     private class Node {
> 42:         private SoftReference<V> ref;

this code looks like a double check locking so ref should be volatile

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From iklam at openjdk.java.net  Tue May 17 05:58:45 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 17 May 2022 05:58:45 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
Message-ID: <wCV6hj4zbb5rrZXFcGAWcNUHKxATBR9fGX9JO30ql9k=.005bbfdf-4fcd-4362-8c5e-ba3968f08010@github.com>

On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use stringStream to simplify controller path assembly

test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63:

> 61:     ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path());
> 62:   }
> 63: }

I found it hard to relate the different paths. Could you create a new struct like this?


struct TestCase {
    char* mount_path;
    char* root_paths;
    char* cgroup_path;
    char* expected_cg_paths;
} = {
  {  "/sys/fs/cgroup/memory",     // mount
       "/",                       // root,
       ....

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From forax at openjdk.java.net  Tue May 17 06:05:44 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 17 May 2022 06:05:44 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
Message-ID: <I0bL2XkzvVdR-1FliPNBSnffI6_RURkgZUWRpon57EI=.0bccda3d-d1d3-40d1-aa03-80f7e2235628@github.com>

On Mon, 16 May 2022 17:40:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BootstrapMethodError -> ExceptionInInitializerError

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 157:

> 155:     }
> 156: 
> 157:     static MethodHandle doSpecialize(MethodHandle leafHandle, CallingSequence callingSequence, ABIDescriptor abi) {

I think thise method should be split in to, one version for the upcall, one for the downcall, i do not see the point of merging the two codes.

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 816:

> 814:             return;
> 815:         }
> 816:         if (con instanceof Integer) {

those can use the instanceof + type pattern

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From thartmann at openjdk.java.net  Tue May 17 06:12:54 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 17 May 2022 06:12:54 GMT
Subject: RFR: 8281712: [REDO] AArch64: Implement string_compare intrinsic
 in SVE
In-Reply-To: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>
References: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>
Message-ID: <BQkOrqTuB99e1qYC3BBmUxRCzFb-rVuzXDSnzS5nqoc=.33b97bf8-3d1e-4b1b-b64c-3d41578a8eca@github.com>

On Mon, 16 May 2022 07:21:27 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> This is the REDO of JDK-8269559 and JDK-8275448. Those two backouts finally turned to be some system zlib issue in AArch64 macOS, and is not related to the patch itself. See [1][2] for details.
> 
> This patch is generally the same as JDK-8275448, which uses SVE to optimize string_compare intrinsics for long string comparisons. I did a rebase with small tweaks to get better performance on recent Neoverse hardware. Test data on systems with different SVE vector sizes:
> 
> 
>    case    delta size  128-bits  256-bits  512-bits
> compareToLL  2   24     0.17%     0.58%     0.00%
> compareToLL  2   36     0.00%    2.25%      0.04%
> compareToLL  2   72     -4.40%   3.87%      -12.82%
> compareToLL  2   128    4.55%    58.31%     13.53%
> compareToLL  2   256    19.39%   69.77%     82.03%
> compareToLL  2   512    1.81%    68.38%     170.93%
> compareToLU  2   24     25.57%   46.98%     54.61%
> compareToLU  2   36     36.03%   70.26%     94.33%
> compareToLU  2   72     35.86%   90.58%     146.04%
> compareToLU  2   128    70.82%   119.19%    266.22%
> compareToLU  2   256    80.77%   146.33%    420.01%
> compareToLU  2   512    94.62%   171.72%    530.87%
> compareToUL  2   24     20.82%   34.48%     62.14%
> compareToUL  2   36     39.77%   60.79%     69.77%
> compareToUL  2   72     35.46%   84.34%     121.90%
> compareToUL  2   128    67.77%   110.97%    220.53%
> compareToUL  2   256    77.05%   160.29%    331.30%
> compareToUL  2   512    91.88%   184.57%    524.21%
> compareToUU  2   24     -0.13%   0.40%      0.00%
> compareToUU  2   36     -9.18%   12.84%     -13.93%
> compareToUU  2   72     1.67%    60.61%     6.69%
> compareToUU  2   128    13.51%   60.33%     55.27%
> compareToUU  2   256    2.55%    62.17%     153.26%
> compareToUU  2   512    4.12%    68.62%     201.68%
> 
> JTreg tests passed on SVE hardware.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8275448
> [2] https://bugs.openjdk.java.net/browse/JDK-8282954

Marked as reviewed by thartmann (Reviewer).

Sure, I already submitted testing yesterday, it all passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8723

From forax at openjdk.java.net  Tue May 17 06:13:00 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 17 May 2022 06:13:00 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
Message-ID: <90FVgw2gmUdqeq6_HDCMfsRiGvEqVpXIq_a4_Cw6Jss=.a8a82f5a-6892-4d30-b53b-45f39632b19c@github.com>

On Mon, 16 May 2022 17:40:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BootstrapMethodError -> ExceptionInInitializerError

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 967:

> 965: 
> 966:     // unaligned constants
> 967:     public final static ValueLayout.OfBoolean JAVA_BOOLEAN_UNALIGNED = JAVA_BOOLEAN;

as far as i understand, those constants are accessed from the bytecode, they should be in their own class to cleanly separate the specializer part and the runtime part.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From forax at openjdk.java.net  Tue May 17 06:16:54 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 17 May 2022 06:16:54 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
Message-ID: <udsXg4-e5WD1mj5ygDb3WpMEgvaM662QY-2CWt-DiVM=.da9c4691-6e39-41a8-86c1-0f7e1a70cba6@github.com>

On Mon, 16 May 2022 17:40:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BootstrapMethodError -> ExceptionInInitializerError

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 943:

> 941:         Z, B, S, C, I, J, F, D, L;
> 942: 
> 943:         static BasicType of(Class<?> cls) {

This seems a duplication of ASM Type class for no good reason, Type.getOpcode(ILOAD) or Type.getOpcode(IRETURN) gives you the proper variant opcode

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From iklam at openjdk.java.net  Tue May 17 06:21:50 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 17 May 2022 06:21:50 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
Message-ID: <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>

On Thu, 12 May 2022 18:09:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use stringStream to simplify controller path assembly

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:

> 90:           }
> 91:           ss.print_raw(_root, last_matching_slash_pos);
> 92:           _path = os::strdup(ss.base());

Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From njian at openjdk.java.net  Tue May 17 06:28:48 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Tue, 17 May 2022 06:28:48 GMT
Subject: RFR: 8281712: [REDO] AArch64: Implement string_compare intrinsic
 in SVE
In-Reply-To: <BQkOrqTuB99e1qYC3BBmUxRCzFb-rVuzXDSnzS5nqoc=.33b97bf8-3d1e-4b1b-b64c-3d41578a8eca@github.com>
References: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>
 <BQkOrqTuB99e1qYC3BBmUxRCzFb-rVuzXDSnzS5nqoc=.33b97bf8-3d1e-4b1b-b64c-3d41578a8eca@github.com>
Message-ID: <PmECFC_DeKvtEq-jErnald1BdxV3ZHBUxZ8_WRw6de4=.9f73f24d-c885-4cc9-9173-c818e3a7c385@github.com>

On Tue, 17 May 2022 06:09:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Sure, I already submitted testing yesterday, it all passed.

Thank you, Tobias!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8723

From stuefe at openjdk.java.net  Tue May 17 07:17:49 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 17 May 2022 07:17:49 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
Message-ID: <jsmEFefV1TES-LeReR8zTwkPT9XovK_V6Gyl1n1NwyY=.d9d7077c-318a-4703-b646-82f7c69f117c@github.com>

On Tue, 17 May 2022 06:18:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use stringStream to simplify controller path assembly
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:
> 
>> 90:           }
>> 91:           ss.print_raw(_root, last_matching_slash_pos);
>> 92:           _path = os::strdup(ss.base());
> 
> Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand.

Maybe factor out the search like this

// Return length of common starting substring. E.g. "cat" for ("cattle", "catnip");
static int find_common_starting_substring(const char* s1, const char* s2) {
...
}

That way its clearer and we can find and move this to utilities if we ever need this in other places.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From jbhateja at openjdk.java.net  Tue May 17 08:11:37 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 17 May 2022 08:11:37 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v5]
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <M2xeDWah3AR4Gd-iKVM6w7vOLSQaqMW4K6jwkowQycA=.bf5b68c4-4d67-48ce-8418-7ca1b9a5779d@github.com>

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Review comments resolution.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Correcting a typo.
 - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: AARCH64 backend changes.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/5e5500cb...df7eb90e

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8425/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=04
  Stats: 38068 lines in 254 files changed: 16705 ins; 16921 del; 4442 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425

PR: https://git.openjdk.java.net/jdk/pull/8425

From sgehwolf at openjdk.java.net  Tue May 17 08:15:40 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 17 May 2022 08:15:40 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <jsmEFefV1TES-LeReR8zTwkPT9XovK_V6Gyl1n1NwyY=.d9d7077c-318a-4703-b646-82f7c69f117c@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
 <jsmEFefV1TES-LeReR8zTwkPT9XovK_V6Gyl1n1NwyY=.d9d7077c-318a-4703-b646-82f7c69f117c@github.com>
Message-ID: <JH9YUX0j7ylapxhxWDk9p5NYdMKAHYAzq-cfzBQfzLE=.fe47a403-c4cd-494e-9098-6fe78cb2bd22@github.com>

On Tue, 17 May 2022 07:14:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:
>> 
>>> 90:           }
>>> 91:           ss.print_raw(_root, last_matching_slash_pos);
>>> 92:           _path = os::strdup(ss.base());
>> 
>> Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand.
>
> Maybe factor out the search like this
> 
> // Return length of common starting substring. E.g. "cat" for ("cattle", "catnip");
> static int find_common_starting_substring(const char* s1, const char* s2) {
> ...
> }
> 
> That way its clearer and we can find and move this to utilities if we ever need this in other places.

OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Tue May 17 08:15:41 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 17 May 2022 08:15:41 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <wCV6hj4zbb5rrZXFcGAWcNUHKxATBR9fGX9JO30ql9k=.005bbfdf-4fcd-4362-8c5e-ba3968f08010@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <wCV6hj4zbb5rrZXFcGAWcNUHKxATBR9fGX9JO30ql9k=.005bbfdf-4fcd-4362-8c5e-ba3968f08010@github.com>
Message-ID: <WBoNsbDS2rWIBcmFh6Khgg4Q_3Nj6QlDNoaU5hCEzTI=.68f8f86a-8b35-463f-8225-ed136614362f@github.com>

On Tue, 17 May 2022 05:55:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use stringStream to simplify controller path assembly
>
> test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63:
> 
>> 61:     ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path());
>> 62:   }
>> 63: }
> 
> I found it hard to relate the different paths. Could you create a new struct like this?
> 
> 
> struct TestCase {
>     char* mount_path;
>     char* root_paths;
>     char* cgroup_path;
>     char* expected_cg_paths;
> } = {
>   {  "/sys/fs/cgroup/memory",     // mount
>        "/",                       // root,
>        ....

Yes, makes sense. Will do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From mik3hall at gmail.com  Tue May 17 08:21:06 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Tue, 17 May 2022 03:21:06 -0500
Subject: [External] : Re: RFR: 8286122: [macos]: App bundle cannot upload
 to Mac App Store due to info.plist embedded in java exe
In-Reply-To: <72E816AA-5F0B-4B58-BA06-9D10F03B37FE@oracle.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <E21D931E-3F2D-4E7C-A633-9E20009F9129@gmail.com>
 <8C1C5A6D-6D14-48B0-8C5A-9D9EE18A78A0@oracle.com>
 <0441CF7A-8653-41E8-B084-A7F4863991D6@gmail.com>
 <0035A912-1C97-4F9A-8598-5EAD12188CEC@oracle.com>
 <DD9D156D-7F46-45A1-9A3E-8FB03B130CE9@gmail.com>
 <72E816AA-5F0B-4B58-BA06-9D10F03B37FE@oracle.com>
Message-ID: <24AD3A9D-051D-4570-8FD0-BDABAF026A64@gmail.com>



> On May 17, 2022, at 12:15 AM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,
> 
> I filed following enhancement for signing user provided app image and yes it will be two step process. Invoke jpackage to generate image, then user can modified it and then invoke jpackage again to sign it.
> https://bugs.openjdk.java.net/browse/JDK-8286850
> 
> For JDK-8286122, I will integrate proposed fix as is. Error will be thrown if user tries to include native commands for Mac App Store image.
> 
> Still not sure if we will provide solution for including native commands with Mac App Store. Including special versions of native commands with jpackage will work only if runtime is generated by jpackage. It will not solve issue with user provided runtime. Also, it is not clear if app updates will require same unique ID based on UUID across app versions.

This enhancement doesn?t directly concern this issue. Although given this enhancement it would be possible to provide a temporary ?hack? fix without building it into jpackage. Where the executables are changed to make them unique in the post-processing step. If it is not your intention to address this issue given this enhancement you would probably have to check the provided application bundle to be sure it doesn?t have the colliding Info.plist native commands. What Apple DTS provided may of had commands for this? I don?t remember. Or you would have to just fail any passed application bundles with native java commands.

From https://bugs.openjdk.java.net/browse/JDK-8286850 <https://bugs.openjdk.java.net/browse/JDK-8286850>

> Generating DMG or PKG from ?app-image with signing enabled will not sign app image as it currently do.

I am not sure you would want to change this. If the developer doesn?t want to do any post-processing of the application bundle then they should be able to use the current invocations unchanged to do this?
I would think if you want post-processing you would generate unsigned applications, post-process, use the enhancement to sign. 


> 
> Also, many functionality provided by native JDK commands can be used via ToolProvider. For example if you include jdk.jpackage module with your app, you should able to use jpackage functionality from your app via ToolProvider without actual jpackage native command.
> 
> Thanks,
> Alexander

Which might be another way this could be useful. If any 3rd parties want to generate their own application bundles they could still use jpackage as the definitive way to sign those.

Thanks 
Mike
> 



From aturbanov at openjdk.java.net  Tue May 17 08:25:08 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 17 May 2022 08:25:08 GMT
Subject: RFR: 8286858: Remove dead code in sun.reflect.misc.MethodUtil
Message-ID: <yNqsZAqSuObV3UY7t5A6Y97uP2qHF5wxmseBBCa4VQw=.f26b2841-fe20-4ba5-b491-dc98f7e75cd2@github.com>

They are unused and leftover since JDK 7.  It's good to remove them.

-------------

Commit messages:
 - [PATCH] Remove unused code in sun.reflect.misc.MethodUtil

Changes: https://git.openjdk.java.net/jdk/pull/8715/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8715&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286858
  Stats: 179 lines in 1 file changed: 4 ins; 170 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8715.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8715/head:pull/8715

PR: https://git.openjdk.java.net/jdk/pull/8715

From mcimadamore at openjdk.java.net  Tue May 17 08:31:03 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 17 May 2022 08:31:03 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v21]
In-Reply-To: <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com>
Message-ID: <kkjZ_1mb_nw2J2x9ZngOzsIfW3L8iV14iyFtzQCRmFA=.ba3d33cb-3175-488a-9860-bf2b3894aa66@github.com>

On Mon, 16 May 2022 16:15:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
>> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
>> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
>> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing ASSERT -> NOT_PRODUCT

src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java line 66:

> 64:     private static final boolean USE_SPEC = Boolean.parseBoolean(
> 65:         GetPropertyAction.privilegedGetProperty("jdk.internal.foreign.ProgrammableInvoker.USE_SPEC", "true"));
> 66:     private static final boolean USE_INTRINSICS = Boolean.parseBoolean(

Do we need to update TestMatrix given that we're removing one dimension in the invokers?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From ngasson at openjdk.java.net  Tue May 17 08:40:56 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 17 May 2022 08:40:56 GMT
Subject: RFR: 8281712: [REDO] AArch64: Implement string_compare intrinsic
 in SVE
In-Reply-To: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>
References: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>
Message-ID: <AIlwVz2HVDY7zwTuwlmKin7TvRMZbVBF3GW1rzsO8dc=.2470558c-74c7-4ac9-86eb-db0cf028dbf9@github.com>

On Mon, 16 May 2022 07:21:27 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> This is the REDO of JDK-8269559 and JDK-8275448. Those two backouts finally turned to be some system zlib issue in AArch64 macOS, and is not related to the patch itself. See [1][2] for details.
> 
> This patch is generally the same as JDK-8275448, which uses SVE to optimize string_compare intrinsics for long string comparisons. I did a rebase with small tweaks to get better performance on recent Neoverse hardware. Test data on systems with different SVE vector sizes:
> 
> 
>    case    delta size  128-bits  256-bits  512-bits
> compareToLL  2   24     0.17%     0.58%     0.00%
> compareToLL  2   36     0.00%    2.25%      0.04%
> compareToLL  2   72     -4.40%   3.87%      -12.82%
> compareToLL  2   128    4.55%    58.31%     13.53%
> compareToLL  2   256    19.39%   69.77%     82.03%
> compareToLL  2   512    1.81%    68.38%     170.93%
> compareToLU  2   24     25.57%   46.98%     54.61%
> compareToLU  2   36     36.03%   70.26%     94.33%
> compareToLU  2   72     35.86%   90.58%     146.04%
> compareToLU  2   128    70.82%   119.19%    266.22%
> compareToLU  2   256    80.77%   146.33%    420.01%
> compareToLU  2   512    94.62%   171.72%    530.87%
> compareToUL  2   24     20.82%   34.48%     62.14%
> compareToUL  2   36     39.77%   60.79%     69.77%
> compareToUL  2   72     35.46%   84.34%     121.90%
> compareToUL  2   128    67.77%   110.97%    220.53%
> compareToUL  2   256    77.05%   160.29%    331.30%
> compareToUL  2   512    91.88%   184.57%    524.21%
> compareToUU  2   24     -0.13%   0.40%      0.00%
> compareToUU  2   36     -9.18%   12.84%     -13.93%
> compareToUU  2   72     1.67%    60.61%     6.69%
> compareToUU  2   128    13.51%   60.33%     55.27%
> compareToUU  2   256    2.55%    62.17%     153.26%
> compareToUU  2   512    4.12%    68.62%     201.68%
> 
> JTreg tests passed on SVE hardware.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8275448
> [2] https://bugs.openjdk.java.net/browse/JDK-8282954

LGTM!

-------------

Marked as reviewed by ngasson (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8723

From mcimadamore at openjdk.java.net  Tue May 17 09:47:40 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 17 May 2022 09:47:40 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
Message-ID: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com>

On Mon, 16 May 2022 17:40:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BootstrapMethodError -> ExceptionInInitializerError

src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 257:

> 255:          * the context's allocator is accessed.
> 256:          */
> 257:         public static Context ofSession() {

Thanks for fixing this

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 131:

> 129:     private int[] scopeSlots;
> 130:     private int curScopeLocalIdx = -1;
> 131:     private int RETURN_ALLOCATOR_IDX = -1;

These are not constants, so it is odd to see the name capitalized

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 291:

> 289:             emitGetStatic(Binding.Context.class, "DUMMY", BINDING_CONTEXT_DESC);
> 290:         } else {
> 291:             emitInvokeStatic(Binding.Context.class, "ofSession", OF_SESSION_DESC);

Maybe this is micro-optimization, but I realized that in reality we probably don't need any scope/session if there are no "ToSegment" bindings.

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 336:

> 334: 
> 335:             if (callingSequence.forUpcall()) {
> 336:                 // for upcalls, recipes have a result, which we handle here

I find this part a bit confusing. The comment speaks about recipes input and outputs, hinting at the fact that downcall bindings have inputs, while upcall bindings have outputs.
In reality, if we look at the bindings themselves, they look pretty symmetric:

* UNBOX_ADDRESS = pops an Addressable and push a long on the stack
* BOX_ADDRESS = pops a long and push a MemoryAddress on the stack

That is, in both cases it appears we have an input and an output (and the binding is just the function which maps one into another).

I think the input/output asymmetry comes in when we consider the full recipes. In downcalls, for a given argument we will have the following sequence:

Binding0, Binding1, ... BindingN-1, VMStore

While for upcalls we will have:

VMLoad, Binding1, Binding2, ... BindingN

So (ignoring return buffer for simplicity), for downcalls, it is obvious that before we can execute Binding0, we need some kind of "input value" (e.g. the value of some local). For upcalls, this is not needed, as the VMLoad binding will basically do that for free.
When we finished executing the bindings, again, for downcalls there's nothing to do, as the chain always ends with a VMStore (which stores binding result into some local), while for upcalls we do need to set the output value explicitly.

In other words, it seems to me that having VMLoad and VMStore in the chains of bindings to be interpreted/specialized does more harm than good here. These low level bindings make sense for the VM code, as the VM needs to know how to load a value from a register, or how to store a value into a register. But in terms of the specializing Java code, these bindings are immaterial. At the same time, the fact that we have these bindings, and that they are virtualized, makes the code hard to follow, as some preparation happens in `BindingSpecializer::specialize`, while some other preparation happens inside `BindingSpecializer::doBindings`, as part of the virtualized impl of VMLoad/VMStore. And, this virtualized implementation ends up doing similar steps as what the preparation code before/after the binding execution does (e.g. for downcalls/VMStore we call setOutput, while for upcalls/VMLoad we call getInput).

All I'm saying here is that, for bindings to work, we _always_ need to call both getInput and setOutput - but it is easy to overlook this when looking at the code, because the getInput/setOutput calls are spread across two different places in the specializing code, perhaps making things more asymmetric than they need to be. (I realize I'm simplifying here, and that some details of the return buffer are not 100% quite as symmetric).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From mcimadamore at openjdk.java.net  Tue May 17 09:47:41 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 17 May 2022 09:47:41 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <mRYW8NaJBMpGHqfTLW81a-rz5b8RRskduLrjUEuYGec=.ae5beab6-233b-4825-9ccb-78ad21aa9199@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <mRYW8NaJBMpGHqfTLW81a-rz5b8RRskduLrjUEuYGec=.ae5beab6-233b-4825-9ccb-78ad21aa9199@github.com>
Message-ID: <YG_z_6zbEHdkIVQ9sYIm897DXFwfKlQ7zudlsqFAqIs=.ee080001-d4a4-4a4e-a4b8-9e91016176a3@github.com>

On Tue, 17 May 2022 05:54:39 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootstrapMethodError -> ExceptionInInitializerError
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 98:
> 
>> 96:     private static final String CLASS_DATA_DESC = methodType(Object.class, MethodHandles.Lookup.class, String.class, Class.class).descriptorString();
>> 97:     private static final String RELEASE0_DESC = methodType(void.class).descriptorString();
>> 98:     private static final String ACQUIRE0_DESC = methodType(void.class).descriptorString();
> 
> calling methodType() is quite slow because of the cache of MethodType so maybe those initialization should be done explicitly in a static block to avoid to recompute methodType(long).descriptorString() several times

What about using MethodTypeDesc/ClassDesc as building block?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From mcimadamore at openjdk.java.net  Tue May 17 09:47:41 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 17 May 2022 09:47:41 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v2]
In-Reply-To: <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com>
Message-ID: <KfYdkZDAFAIhEmiKt5koncrp07nvotIKoHVYgYWB1Nw=.5dd1fa87-91bd-40fb-abea-d5262549e328@github.com>

On Fri, 13 May 2022 13:23:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change)

src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequence.java line 109:

> 107:      * @return the caller method type.
> 108:      */
> 109:     public MethodType callerMethodType() {

Would it make sense to either rename these, or to point to the fact that these are equivalent to Linker::downcallType/upcallType ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From jvernee at openjdk.java.net  Tue May 17 10:06:05 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 May 2022 10:06:05 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v21]
In-Reply-To: <kkjZ_1mb_nw2J2x9ZngOzsIfW3L8iV14iyFtzQCRmFA=.ba3d33cb-3175-488a-9860-bf2b3894aa66@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com>
 <kkjZ_1mb_nw2J2x9ZngOzsIfW3L8iV14iyFtzQCRmFA=.ba3d33cb-3175-488a-9860-bf2b3894aa66@github.com>
Message-ID: <y7Y7BRmRhM5FkJ68Uz0DlxCk7by6Bv87MjSYHwvR8hE=.3037536f-bf26-46ec-82ca-27aa24b2d4d5@github.com>

On Tue, 17 May 2022 08:27:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing ASSERT -> NOT_PRODUCT
>
> src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java line 66:
> 
>> 64:     private static final boolean USE_SPEC = Boolean.parseBoolean(
>> 65:         GetPropertyAction.privilegedGetProperty("jdk.internal.foreign.ProgrammableInvoker.USE_SPEC", "true"));
>> 66:     private static final boolean USE_INTRINSICS = Boolean.parseBoolean(
> 
> Do we need to update TestMatrix given that we're removing one dimension in the invokers?

Looks like that already happened as part of the main JEP integration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Tue May 17 10:11:57 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 May 2022 10:11:57 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com>
Message-ID: <4HyW0Kv4vN-7wXdlxTzXFer1oLP6e2w_Z3XlxZT5w00=.f066b4a6-e471-43a3-873c-d5d6db9cbb95@github.com>

On Tue, 17 May 2022 08:32:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootstrapMethodError -> ExceptionInInitializerError
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 131:
> 
>> 129:     private int[] scopeSlots;
>> 130:     private int curScopeLocalIdx = -1;
>> 131:     private int RETURN_ALLOCATOR_IDX = -1;
> 
> These are not constants, so it is odd to see the name capitalized

Right, habit of writing lambda forms, where name variables are capitalized.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From jvernee at openjdk.java.net  Tue May 17 10:22:57 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 May 2022 10:22:57 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v2]
In-Reply-To: <KfYdkZDAFAIhEmiKt5koncrp07nvotIKoHVYgYWB1Nw=.5dd1fa87-91bd-40fb-abea-d5262549e328@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com>
 <KfYdkZDAFAIhEmiKt5koncrp07nvotIKoHVYgYWB1Nw=.5dd1fa87-91bd-40fb-abea-d5262549e328@github.com>
Message-ID: <htVlkP1pXKFYlm3-1_cmxGosRoNGQyX4OJRjoS7HS1c=.39150fb5-d9b8-4691-a7f1-20fb6a7bb827@github.com>

On Mon, 16 May 2022 12:58:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change)
>
> src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequence.java line 109:
> 
>> 107:      * @return the caller method type.
>> 108:      */
>> 109:     public MethodType callerMethodType() {
> 
> Would it make sense to either rename these, or to point to the fact that these are equivalent to Linker::downcallType/upcallType ?

I don't think renaming them to down/upcallType makes sense, since both down/up calls use both the caller and callee method type. There can also be things that make these not equivalent to downcallType/upcallType, such as the SysV need to pass the number of floating point arguments for variadic calls as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java#L109-L111

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From jvernee at openjdk.java.net  Tue May 17 10:38:39 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 May 2022 10:38:39 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v22]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <VAvDKTRdGkwBRlzCYNvNtTZbzrv8J4w6FBW0fGWp5Xc=.98c0cd19-f9b6-424f-b8a0-2880587d4bda@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  ifdef NOT_PRODUCT -> ifndef PRODUCT

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7959/files
  - new: https://git.openjdk.java.net/jdk/pull/7959/files/406f3e83..c3abb732

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=20-21

  Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From jvernee at openjdk.java.net  Tue May 17 11:21:49 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 May 2022 11:21:49 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <udsXg4-e5WD1mj5ygDb3WpMEgvaM662QY-2CWt-DiVM=.da9c4691-6e39-41a8-86c1-0f7e1a70cba6@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <udsXg4-e5WD1mj5ygDb3WpMEgvaM662QY-2CWt-DiVM=.da9c4691-6e39-41a8-86c1-0f7e1a70cba6@github.com>
Message-ID: <unIxDAPY0Fqrh5qJuZEECdzi8GFmpCfmGBB5FyadpX4=.642cd620-6d5e-4784-87b9-f14db8e4ab9e@github.com>

On Tue, 17 May 2022 06:13:04 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootstrapMethodError -> ExceptionInInitializerError
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 943:
> 
>> 941:         Z, B, S, C, I, J, F, D, L;
>> 942: 
>> 943:         static BasicType of(Class<?> cls) {
> 
> This seems a duplication of ASM Type class for no good reason, Type.getOpcode(ILOAD) or Type.getOpcode(IRETURN) gives you the proper variant opcode

Didn't know about that. Neat!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From jvernee at openjdk.java.net  Tue May 17 12:01:44 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 May 2022 12:01:44 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <mRYW8NaJBMpGHqfTLW81a-rz5b8RRskduLrjUEuYGec=.ae5beab6-233b-4825-9ccb-78ad21aa9199@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <mRYW8NaJBMpGHqfTLW81a-rz5b8RRskduLrjUEuYGec=.ae5beab6-233b-4825-9ccb-78ad21aa9199@github.com>
Message-ID: <766Q0H0VVoOXTVMM_IB-ZufIxO74PmF77-rFVmzlz3s=.9ffd2e8d-66e2-4f63-8b5d-a3542e3de4dd@github.com>

On Tue, 17 May 2022 05:51:58 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootstrapMethodError -> ExceptionInInitializerError
>
> src/java.base/share/classes/jdk/internal/foreign/abi/SoftReferenceCache.java line 42:
> 
>> 40: 
>> 41:     private class Node {
>> 42:         private SoftReference<V> ref;
> 
> this code looks like a double check locking so ref should be volatile

Thanks. I thought the `moniterenter` & `monitorexit` were enough here for visibility. I've read up on this and it looks like `volatile` is needed to correctly order the constructor and apply call (and contents) before the write to the `ref` field.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From ihse at openjdk.java.net  Tue May 17 12:14:52 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 17 May 2022 12:14:52 GMT
Subject: Integrated: 8285485: Fix typos in corelibs
In-Reply-To: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
References: <VgOAsZFnt69XV-QiirD5sI0CfBQ7E-AojH-s4V8v_KY=.d89f723f-3770-481f-a0cf-11e846f767cf@github.com>
Message-ID: <FB4xTFBBS1ehsyx5l9hPh0YTh3MKvBh1_BvR7wDpmmQ=.960babb2-67ec-4007-a097-7291478cdb3d@github.com>

On Fri, 22 Apr 2022 15:08:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran `codespell` on modules owned by core-libs, and accepted those changes where it indeed discovered real typos.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

This pull request has now been integrated.

Changeset: e68024c2
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e68024c2d28d634ebfde7f2fdcc35f5d7b07d704
Stats:     295 lines in 101 files changed: 0 ins; 0 del; 295 mod

8285485: Fix typos in corelibs

Reviewed-by: jpai, sundar, naoto, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8364

From rehn at openjdk.java.net  Tue May 17 12:27:11 2022
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 17 May 2022 12:27:11 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v22]
In-Reply-To: <VAvDKTRdGkwBRlzCYNvNtTZbzrv8J4w6FBW0fGWp5Xc=.98c0cd19-f9b6-424f-b8a0-2880587d4bda@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
 <VAvDKTRdGkwBRlzCYNvNtTZbzrv8J4w6FBW0fGWp5Xc=.98c0cd19-f9b6-424f-b8a0-2880587d4bda@github.com>
Message-ID: <jwdW7pA71xcylSVhLZVV84v3XC_w15ebD5vndqB7pyA=.fcb3adb7-e86b-42b7-b9c0-ed78d51cb549@github.com>

On Tue, 17 May 2022 10:38:39 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
>> 
>> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
>> 
>> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
>> 
>> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
>> 
>> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
>> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
>> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
>> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
>> 
>> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
>> 
>> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
>> 
>> Testing: Tier1-4
>> 
>> Thanks,
>> Jorn
>> 
>> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
>> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
>> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
>> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
>> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
>> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
>> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
>> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
>> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ifdef NOT_PRODUCT -> ifndef PRODUCT

Looks good, thanks.

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7959

From ysuenaga at openjdk.java.net  Tue May 17 12:41:16 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 12:41:16 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
Message-ID: <dVXnKoWIZQ8G3OcOYUpF6H1KYa3LKo_yJ7s1la_LrFg=.b86fe65e-c24b-4102-b1b6-9278411b9efb@github.com>

On Tue, 17 May 2022 01:43:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change for java.c , parse_manifest.c , LinuxPackage.c
>
> src/hotspot/share/classfile/classFileParser.cpp line 5970:
> 
>> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED
>> 5969:   _cp->symbol_at_put(hidden_index, _class_name);
>> 5970: PRAGMA_DIAG_POP
> 
> I don't understand these warning suppressions for symbol_at_put (here and elsewhere).  I don't see any stringops here.  What is the compiler complaining about?  (There's no mention of classfile stuff in the review cover message.)

Like the others, it is caused by `Array::at_put()`.


In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28,
                 from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29,
                 from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30,
                 from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35:
In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
    inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
    inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15,
    inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21:

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Tue May 17 12:46:03 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 12:46:03 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
Message-ID: <hIsWyYSlUhRP7C95ZRVgCsbEM-16ZKIPg0Wf4u9OG5g=.81981efb-c599-4474-bbb9-d71786b6ab55@github.com>

On Tue, 17 May 2022 03:02:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change for java.c , parse_manifest.c , LinuxPackage.c
>
> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103:
> 
>> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED
>> 102:   *dest = op(bits, *dest);
>> 103: PRAGMA_DIAG_POP
> 
> I see no stringop here.  I'm still trying to understand what the compiler is complaining about.

I guess GCC cannot understand `assert(dest != NULL` immediately preceding it.


In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33,
                 from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30,
                 from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30:
In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]',
    inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23,
    inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6,
    inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3,
    inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35:

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From asotona at openjdk.java.net  Tue May 17 12:55:21 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 17 May 2022 12:55:21 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image containing
 jdk.compiler fails with --enable-preview option
Message-ID: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>

### Problem description
Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
fails to run java source launcher correctly (for example when --source N is specified).
Failing source launcher is the only one expression of internal jdk.compiler malfunction, another example is failure to run javac with --release option.

### Root cause
Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
However module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.

### Alternative patch
The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module).

### Proposed fix
This patch does fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
Plus added specific test case.

Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.

Thanks,
Adam

-------------

Commit messages:
 - 8286571: java source launcher from a minimal jdk image containing jdk.compiler fails with --enable-preview option

Changes: https://git.openjdk.java.net/jdk/pull/8747/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286571
  Stats: 30 lines in 2 files changed: 29 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8747/head:pull/8747

PR: https://git.openjdk.java.net/jdk/pull/8747

From asotona at openjdk.java.net  Tue May 17 13:08:32 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 17 May 2022 13:08:32 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v2]
In-Reply-To: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
Message-ID: <B3jOs2mD5UAbmSdS0IYbIu3qVb5dl5dBsWekJQT6OUU=.e0b461a2-bc82-4c57-aa7c-f8415a61dbef@github.com>

> ### Problem description
> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
> fails to run java source launcher correctly (for example when --source N is specified).
> Failing source launcher is the only one expression of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
> 
> ### Root cause
> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
> However module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
> 
> ### Alternative patch
> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module).
> 
> ### Proposed fix
> This patch does fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
> Plus added specific test case.
> 
> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fix of LimitedImage test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8747/files
  - new: https://git.openjdk.java.net/jdk/pull/8747/files/40884fd8..6bdf4a9a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=00-01

  Stats: 45 lines in 1 file changed: 0 ins; 37 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8747/head:pull/8747

PR: https://git.openjdk.java.net/jdk/pull/8747

From ysuenaga at openjdk.java.net  Tue May 17 13:15:24 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 13:15:24 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v6]
In-Reply-To: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
Message-ID: <SHrm-ZwMXXorwXm1z63bQV1DDA7HkJ2FMzU1G4DsuAw=.f2102c78-97e5-4626-9d5c-f3ad09c89d1d@github.com>

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
> 
> * -Wstringop-overflow
>     * src/hotspot/share/oops/array.hpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
> 
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Add assert to check the range of BasicType
 - Merge remote-tracking branch 'upstream/master' into HEAD
 - Revert change for java.c , parse_manifest.c , LinuxPackage.c
 - Calculate char offset before realloc()
 - Use return value from JLI_Snprintf
 - Avoid pragma error in before GCC 12
 - 8286562: GCC 12 reports some compiler warnings

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8646/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=05
  Stats: 56 lines in 11 files changed: 46 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646

PR: https://git.openjdk.java.net/jdk/pull/8646

From aturbanov at openjdk.java.net  Tue May 17 13:21:48 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 17 May 2022 13:21:48 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <bdyMScRIzJTzmKnpU9Bdu7Qe7gv9r1te5Yw6yVYsk4o=.ab88908e-33aa-4efe-8d80-3ad8cda92483@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Any more reviewers, please?)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From ysuenaga at openjdk.java.net  Tue May 17 13:24:50 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 13:24:50 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
Message-ID: <63OHghBxNm4xJxaud2ThDD4e3TN_ENSU4Yeh2wZcqR4=.0bcbd897-c9a3-4e48-9416-47deb17c777e@github.com>

On Tue, 17 May 2022 03:14:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change for java.c , parse_manifest.c , LinuxPackage.c
>
> src/hotspot/share/classfile/bytecodeAssembler.cpp line 95:
> 
>> 93:         ShouldNotReachHere();
>> 94:     }
>> 95: PRAGMA_DIAG_POP
> 
> One of these is another of the symbol_at_put cases that I don't understand.  Are there other cases in the switch that warn?  And if so, which ones and how?  There are no details of this one in the PR cover description.

Most of switch cases are warned. Please see [logs](https://github.com/openjdk/jdk/files/8708578/hotspot_variant-server_libjvm_objs_bytecodeAssembler.o.log)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Tue May 17 13:32:42 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 13:32:42 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v7]
In-Reply-To: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
Message-ID: <F7pDEuGXdRxaZ1L8KgQWJ7UIW5z7cEhXcF8ZOSPpwXo=.5a8df23a-e126-4e51-b2a8-db45e3e4424a@github.com>

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
> 
> * -Wstringop-overflow
>     * src/hotspot/share/oops/array.hpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
> 
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  revert changes for memnode.cpp and type.cpp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8646/files
  - new: https://git.openjdk.java.net/jdk/pull/8646/files/73c306d7..88cbf46d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=05-06

  Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Tue May 17 13:32:43 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 13:32:43 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <njyWT3_tTXhWhjVC2ORdNf3PESMANtf0H2eDg9ColEw=.6347983e-51b8-428c-93ab-522ed23afba2@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
 <njyWT3_tTXhWhjVC2ORdNf3PESMANtf0H2eDg9ColEw=.6347983e-51b8-428c-93ab-522ed23afba2@github.com>
Message-ID: <GcbyXua7z1d9VvM82kBeRT2Hx9xUyKAYEqUuFyPrLEE=.c8949e55-7a9d-4826-9692-6bcf8f970736@github.com>

On Tue, 17 May 2022 04:52:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/opto/memnode.cpp line 1413:
>> 
>>> 1411:                    bt == T_BYTE    || bt == T_SHORT ||
>>> 1412:                    bt == T_INT     || bt == T_LONG, "wrong type = %s", type2name(bt));
>>> 1413: PRAGMA_DIAG_POP
>> 
>> The problem here is the definition of type2name, which returns NULL for an unknown BasicType.  It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source.
>
> While looking at type2name, I noticed the comment for the immediately preceding type2name_tab is wrong.

The warning has gone in new commit, and I fixed the comment for `type2name_tab` in it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Tue May 17 13:32:45 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 13:32:45 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
Message-ID: <-VtXM4fP_wQp_OWiDuU5FmEvFfDK8Y6_lJ7xHI2doYM=.0a7e6002-9b6a-4bdd-b508-7510fe82230c@github.com>

On Tue, 17 May 2022 03:06:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert change for java.c , parse_manifest.c , LinuxPackage.c
>
> src/hotspot/share/opto/type.cpp line 4300:
> 
>> 4298: PRAGMA_FORMAT_OVERFLOW_IGNORED
>> 4299:       fatal("not an element type: %s", type2name(etype));
>> 4300: PRAGMA_DIAG_POP
> 
> Another occurrence of type2name returning NULL for unknown BasicType.

The warning has gone in new commit due to change of `type2name`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Tue May 17 13:55:43 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 13:55:43 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher [v2]
In-Reply-To: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
Message-ID: <kpwhZV6rm7YXl9P4Z7xAzqv87DzvP-emA7s0VjiPyqQ=.7c71f621-b2ac-402d-a4e3-271d89eb542f@github.com>

> GCC 12 reports as following:

Yasumasa Suenaga 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:

 - Use assert() to check jargv
 - Merge remote-tracking branch 'upstream/master' into JDK-8286694
 - 8286694: Incorrect argument processing in java launcher

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8694/files
  - new: https://git.openjdk.java.net/jdk/pull/8694/files/fbde50b2..339dc135

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8694&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8694&range=00-01

  Stats: 6334 lines in 527 files changed: 3166 ins; 1506 del; 1662 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8694.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8694/head:pull/8694

PR: https://git.openjdk.java.net/jdk/pull/8694

From ysuenaga at openjdk.java.net  Tue May 17 13:58:37 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 17 May 2022 13:58:37 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher
In-Reply-To: <yqxakAeLdUFdD1b3j4KiYqrZQOFp1Rm5qUxdBnsdDKs=.83a764c8-3664-4bba-a196-41070afd7fd8@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
 <yqxakAeLdUFdD1b3j4KiYqrZQOFp1Rm5qUxdBnsdDKs=.83a764c8-3664-4bba-a196-41070afd7fd8@github.com>
Message-ID: <77vg1jdikWjo9b08yeLPCjrvml1pbNnK7n14Tu4YHZg=.d2bb1356-1bde-46c8-9877-a57cb909fb66@github.com>

On Tue, 17 May 2022 04:39:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> GCC 12 reports as following:
>
> You forced me to look at this in depth. The values are set via the build system. In the build system it is impossible to get just -J because the -J is only added as a prefix for an existing string. So basically this is impossible code to reach unless you manually override the build system definition. So as far as I can see this is a classic case where we want an assert.
> 
> 
> if (arg[0] == '-' && arg[1] == 'J') {
>     assert(arg[2] != '\0', "Invalid JAVA_ARGS or EXTRA_JAVA_ARGS defined by build");
>     *nargv++ = JLI_StringDup(arg + 2);
> }

@dholmes-ora Thanks for your comment!

We cannot use `assert(cond, message)` at here because it is not HotSpot code. In imageFile.cpp for libjimage. It uses `assert(cond && message)`, so I use this style in new commit, and the warning has gone.

I can change to "normal" `assert` usage at here if it is strange.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From duke at openjdk.java.net  Tue May 17 14:20:20 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 17 May 2022 14:20:20 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set with
 TZ env variable
Message-ID: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>

This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

-------------

Commit messages:
 - 8285838: Fix for TZ environment variable DST rules

Changes: https://git.openjdk.java.net/jdk/pull/8661/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285838
  Stats: 139 lines in 3 files changed: 138 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8661/head:pull/8661

PR: https://git.openjdk.java.net/jdk/pull/8661

From robilad at openjdk.java.net  Tue May 17 14:20:20 2022
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Tue, 17 May 2022 14:20:20 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable
In-Reply-To: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
Message-ID: <Wq45s39AuCt7SXpYIm2PgtlscSPLXEd5wqrekLjtXXE=.ca11a7ce-e7f7-4924-8123-7134045c068b@github.com>

On Wed, 11 May 2022 18:00:31 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Hi, please send me an e-mail at Dalibor.topic at oracle.com, so that I can mark your account as verified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From duke at openjdk.java.net  Tue May 17 14:20:21 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 17 May 2022 14:20:21 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable
In-Reply-To: <Wq45s39AuCt7SXpYIm2PgtlscSPLXEd5wqrekLjtXXE=.ca11a7ce-e7f7-4924-8123-7134045c068b@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <Wq45s39AuCt7SXpYIm2PgtlscSPLXEd5wqrekLjtXXE=.ca11a7ce-e7f7-4924-8123-7134045c068b@github.com>
Message-ID: <0TgrauJHrnHHGSmvbOl-FtaQONNQcCME-9_4qw-o2fc=.01f2211e-87ab-43fe-93eb-c280f7431e1f@github.com>

On Wed, 11 May 2022 21:20:52 GMT, Dalibor Topic <robilad at openjdk.org> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Hi, please send me an e-mail at Dalibor.topic at oracle.com, so that I can mark your account as verified.

I've sent an email yesterday @robilad

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From forax at openjdk.java.net  Tue May 17 14:33:50 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 17 May 2022 14:33:50 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <YG_z_6zbEHdkIVQ9sYIm897DXFwfKlQ7zudlsqFAqIs=.ee080001-d4a4-4a4e-a4b8-9e91016176a3@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <mRYW8NaJBMpGHqfTLW81a-rz5b8RRskduLrjUEuYGec=.ae5beab6-233b-4825-9ccb-78ad21aa9199@github.com>
 <YG_z_6zbEHdkIVQ9sYIm897DXFwfKlQ7zudlsqFAqIs=.ee080001-d4a4-4a4e-a4b8-9e91016176a3@github.com>
Message-ID: <BFg4ZXQ6pYURbBRUCoHyw18fBkuD6xv_KM5qQbKv1Ow=.adf59459-b21f-4e57-b430-f391bf6a10db@github.com>

On Tue, 17 May 2022 08:16:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 98:
>> 
>>> 96:     private static final String CLASS_DATA_DESC = methodType(Object.class, MethodHandles.Lookup.class, String.class, Class.class).descriptorString();
>>> 97:     private static final String RELEASE0_DESC = methodType(void.class).descriptorString();
>>> 98:     private static final String ACQUIRE0_DESC = methodType(void.class).descriptorString();
>> 
>> calling methodType() is quite slow because of the cache of MethodType so maybe those initialization should be done explicitly in a static block to avoid to recompute methodType(long).descriptorString() several times
>
> What about using MethodTypeDesc/ClassDesc as building block?

yes, it should be less expensive, the ClassDesc still need to be constructed from Class to allow refactoring.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From forax at openjdk.java.net  Tue May 17 14:33:52 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 17 May 2022 14:33:52 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <766Q0H0VVoOXTVMM_IB-ZufIxO74PmF77-rFVmzlz3s=.9ffd2e8d-66e2-4f63-8b5d-a3542e3de4dd@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <mRYW8NaJBMpGHqfTLW81a-rz5b8RRskduLrjUEuYGec=.ae5beab6-233b-4825-9ccb-78ad21aa9199@github.com>
 <766Q0H0VVoOXTVMM_IB-ZufIxO74PmF77-rFVmzlz3s=.9ffd2e8d-66e2-4f63-8b5d-a3542e3de4dd@github.com>
Message-ID: <b6eqyiS91ximQoKgwzXG3VnK6VvgZLpruiHw_4P_mW4=.407de926-9007-44f8-823d-29a788c9ddcd@github.com>

On Tue, 17 May 2022 11:57:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/SoftReferenceCache.java line 42:
>> 
>>> 40: 
>>> 41:     private class Node {
>>> 42:         private SoftReference<V> ref;
>> 
>> this code looks like a double check locking so ref should be volatile
>
> Thanks. I thought the `moniterenter` & `monitorexit` were enough here for visibility. I've read up on this and it looks like `volatile` is needed to correctly order the constructor and apply call (and contents) before the write to the `ref` field.

yes, otherwise another thread than the one inside the `monitorenter`/`monitorexit` that is initializing the object can see the object half initialized.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From alanb at openjdk.java.net  Tue May 17 15:06:21 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 17 May 2022 15:06:21 GMT
Subject: RFR: 8286788: Test
 java/lang/Thread/virtual/ThreadAPI.testGetStackTrace3 fails
Message-ID: <usB7VoTJ_v6MfYT3ZtcSRqbQ2gkRC-di9NOoR5CzEaQ=.a61785dc-aebe-459f-aa19-d65f05d13ed5@github.com>

This is a test fix. ThreadAPI.testGetStackTrace3 tests Thread::getStackTrace on a thread doing a selection operation. The test is not reliable as it expects to see the "select" method in the stack trace after waiting 200ms. The test is changed to poll the stack trace so that it's no longer dependent on sleep.

The update includes a drive-by change to the test description to use `@enablePreview`.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/8743/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8743&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286788
  Stats: 10 lines in 1 file changed: 3 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8743.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8743/head:pull/8743

PR: https://git.openjdk.java.net/jdk/pull/8743

From jvernee at openjdk.java.net  Tue May 17 15:26:08 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 May 2022 15:26:08 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <BFg4ZXQ6pYURbBRUCoHyw18fBkuD6xv_KM5qQbKv1Ow=.adf59459-b21f-4e57-b430-f391bf6a10db@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <mRYW8NaJBMpGHqfTLW81a-rz5b8RRskduLrjUEuYGec=.ae5beab6-233b-4825-9ccb-78ad21aa9199@github.com>
 <YG_z_6zbEHdkIVQ9sYIm897DXFwfKlQ7zudlsqFAqIs=.ee080001-d4a4-4a4e-a4b8-9e91016176a3@github.com>
 <BFg4ZXQ6pYURbBRUCoHyw18fBkuD6xv_KM5qQbKv1Ow=.adf59459-b21f-4e57-b430-f391bf6a10db@github.com>
Message-ID: <4qq76p-B4KhP--Kkk7mgjLMQFyEacYv5GfqqCGCk2KA=.62383464-9935-430d-bb5a-0b8ffaac30dc@github.com>

On Tue, 17 May 2022 14:28:11 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> What about using MethodTypeDesc/ClassDesc as building block?
>
> yes, it should be less expensive, the ClassDesc still need to be constructed from Class to allow refactoring.

Can't wait for constant folding :)

I'll pull the `methodType(void.class).descriptorString()` into a separate constant, and reuse that.

I don't think it's worth it to spend too much time here at this point though, since this code is only executed once.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From duke at openjdk.java.net  Tue May 17 15:36:03 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 17 May 2022 15:36:03 GMT
Subject: RFR: 8213045: Add BigDecimal.TWO [v2]
In-Reply-To: <TvonkfJ6jVIUm6dDWwmsi2mDEV0WgoeGRGFTzUCfrR0=.3e627e2a-91d7-4d28-a67b-274e4f2cbc30@github.com>
References: <KEY7pcoz01lL7ePNaD9N7HTqCsde-QBVqkY7c6oJ7xE=.6b0623a6-a452-4212-ba4e-b45061ec4f52@github.com>
 <TvonkfJ6jVIUm6dDWwmsi2mDEV0WgoeGRGFTzUCfrR0=.3e627e2a-91d7-4d28-a67b-274e4f2cbc30@github.com>
Message-ID: <I2i2jpq1k0CStl1gWWKOCkpr4CQwpU1NG49dV3NLhGo=.5dbe2b8a-f125-4384-adc8-2b30fc30fb84@github.com>

On Mon, 16 May 2022 22:34:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add constant `java.math.BigDecimal.TWO`.
>
> Brian Burkhalter 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:
> 
>   8213045: Add BigDecimal.TWO

Looks good

-------------

PR: https://git.openjdk.java.net/jdk/pull/8735

From naoto at openjdk.java.net  Tue May 17 15:49:53 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 17 May 2022 15:49:53 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v9]
In-Reply-To: <gW6MccDl1j5z1UTgET1Ea8MTnZCKcoMKjcG33LkKzTQ=.de8ad983-825f-4090-9c7e-1d369d289488@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <gW6MccDl1j5z1UTgET1Ea8MTnZCKcoMKjcG33LkKzTQ=.de8ad983-825f-4090-9c7e-1d369d289488@github.com>
Message-ID: <ehVIzLYeXdgg3MTbWq0oFb8l2VTIpQJvFE7GjPgjLJE=.6bdd70ff-f7cf-4ffb-bd57-8131591bff7a@github.com>

On Tue, 17 May 2022 01:19:30 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

Looks good. Thanks for the fix!

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8378

From jvernee at openjdk.java.net  Tue May 17 15:53:05 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 May 2022 15:53:05 GMT
Subject: RFR: 8283689: Update the foreign linker VM implementation [v23]
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <FkhRmxrM_fiMraqRZY_yiB1SH3VKvKq-hjSquZTIKfQ=.0a521142-b817-4f40-bd1e-9b031fe6e55f@github.com>

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:

 - Merge branch 'master' into JEP-19-VM-IMPL2
 - ifdef NOT_PRODUCT -> ifndef PRODUCT
 - Missing ASSERT -> NOT_PRODUCT
 - Cleanup UL usage
 - Fix failure with SPEC disabled (accidentally dropped change)
 - indentation
 - fix space
 - Merge branch 'master' into JEP-19-VM-IMPL2
 - Undo spurious changes.
 - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2
 - ... and 95 more: https://git.openjdk.java.net/jdk/compare/af07919e...c3c1421b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7959/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=22
  Stats: 6914 lines in 155 files changed: 2577 ins; 3219 del; 1118 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7959.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959

PR: https://git.openjdk.java.net/jdk/pull/7959

From darcy at openjdk.java.net  Tue May 17 15:55:42 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 17 May 2022 15:55:42 GMT
Subject: RFR: 8286788: Test
 java/lang/Thread/virtual/ThreadAPI.testGetStackTrace3 fails
In-Reply-To: <usB7VoTJ_v6MfYT3ZtcSRqbQ2gkRC-di9NOoR5CzEaQ=.a61785dc-aebe-459f-aa19-d65f05d13ed5@github.com>
References: <usB7VoTJ_v6MfYT3ZtcSRqbQ2gkRC-di9NOoR5CzEaQ=.a61785dc-aebe-459f-aa19-d65f05d13ed5@github.com>
Message-ID: <sSLvyWWF_Gvct0wc_KJY42eSg_Bld1Vr50lF3RConGg=.c239fa90-a90c-4e66-83c4-0b65b2a33e3b@github.com>

On Tue, 17 May 2022 11:15:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test fix. ThreadAPI.testGetStackTrace3 tests Thread::getStackTrace on a thread doing a selection operation. The test is not reliable as it expects to see the "select" method in the stack trace after waiting 200ms. The test is changed to poll the stack trace so that it's no longer dependent on sleep.
> 
> The update includes a drive-by change to the test description to use `@enablePreview`.

Marked as reviewed by darcy (Reviewer).

test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 28:

> 26:  * @bug 8284161 8286788
> 27:  * @summary Test Thread API with virtual threads
> 28:  * @enablePreview

Good to see there is directed jtreg support for this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8743

From duke at openjdk.java.net  Tue May 17 15:59:52 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 17 May 2022 15:59:52 GMT
Subject: Integrated: 8286810: Use public [Double|Float].PRECISION fields in
 jdk.internal.math.[Double|Float]Consts
In-Reply-To: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
References: <KI1oxyrcxkt5fS3VRfimb6FenHOPyl0z1pBF7vZoCwc=.59a626a8-6e11-4a9d-af78-9879f39fe790@github.com>
Message-ID: <8Mkn2S6qDJ-tzOj1ZTbhOzAmc9V7nsw6yZiSFT-vQ1Q=.ebcda2fb-1388-4038-ab5c-cfb053844b6f@github.com>

On Mon, 16 May 2022 14:48:43 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> Please review these simple changes in jdk.internal.math.[Double|Float]Consts

This pull request has now been integrated.

Changeset: ea713c37
Author:    Raffaello Giulietti <raffaello.giulietti at oracle.com>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ea713c37fb7eb628c46ad8838425a0029f24be9d
Stats:     41 lines in 2 files changed: 12 ins; 5 del; 24 mod

8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts

Reviewed-by: bpb, rriggs, darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/8729

From jpai at openjdk.java.net  Tue May 17 15:59:55 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 17 May 2022 15:59:55 GMT
Subject: RFR: 8286788: Test
 java/lang/Thread/virtual/ThreadAPI.testGetStackTrace3 fails
In-Reply-To: <usB7VoTJ_v6MfYT3ZtcSRqbQ2gkRC-di9NOoR5CzEaQ=.a61785dc-aebe-459f-aa19-d65f05d13ed5@github.com>
References: <usB7VoTJ_v6MfYT3ZtcSRqbQ2gkRC-di9NOoR5CzEaQ=.a61785dc-aebe-459f-aa19-d65f05d13ed5@github.com>
Message-ID: <aYMZUiwIJ0OkOkhQg3yyLgBDw9GFgZvd-3DGNJeE9VA=.155658e8-797e-4996-b85b-2f861f4f810d@github.com>

On Tue, 17 May 2022 11:15:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test fix. ThreadAPI.testGetStackTrace3 tests Thread::getStackTrace on a thread doing a selection operation. The test is not reliable as it expects to see the "select" method in the stack trace after waiting 200ms. The test is changed to poll the stack trace so that it's no longer dependent on sleep.
> 
> The update includes a drive-by change to the test description to use `@enablePreview`.

Looks fine to me.

The documentation of `@enablePreview` states:
> If a test declares that it uses preview features, these additional options will be provided automatically, for all @run main and @compile actions, including implicit @compile actions generated by @build actions.

The test here is using `testng` and not `main`, but I think it's more a documentation issue since it appears that the test is running fine in GitHub Actions job:


2022-05-17T12:12:50.5073267Z TEST: java/lang/Thread/virtual/ThreadAPI.java
2022-05-17T12:12:50.5073898Z   build: 0.138 seconds
2022-05-17T12:12:50.5074531Z   compile: 0.138 seconds
2022-05-17T12:12:50.5074992Z   testng: 32.421 seconds
2022-05-17T12:12:50.5076274Z TEST RESULT: Passed. Execution successful
2022-05-17T12:12:50.5076900Z

-------------

Marked as reviewed by jpai (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8743

From naoto at openjdk.java.net  Tue May 17 16:06:49 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 17 May 2022 16:06:49 GMT
Subject: RFR: 8282280: Update Xerces to Version 2.12.2 [v2]
In-Reply-To: <3y07XSVou7GU8asGFL6HZ99bhd-i87hMAOBD3yDdusQ=.336f474c-5317-4bcd-8ac2-281d7f30c2a4@github.com>
References: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
 <3y07XSVou7GU8asGFL6HZ99bhd-i87hMAOBD3yDdusQ=.336f474c-5317-4bcd-8ac2-281d7f30c2a4@github.com>
Message-ID: <p8sEXM459Bv3W8Vocy-kKb9aCmqAO7X-qnIu3F7cS3U=.5c668a92-7183-4201-abbb-f423b0f84e08@github.com>

On Tue, 17 May 2022 00:39:37 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Update to Xerces 2.12.2.
>> 
>> The update also fixes JDK-8144117. Added a test.
>> 
>> Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this update. See related issue report.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   provider description

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8732

From darcy at openjdk.java.net  Tue May 17 16:18:50 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 17 May 2022 16:18:50 GMT
Subject: Integrated: JDK-8286783: Expand use of @inheritDoc in InputStream and
 OutputStream subclasses
In-Reply-To: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
References: <tCzS8J4XhQFW0eHcvNr26qCEI0DHaPju4EGl4jrmb3o=.dbe3c127-734e-4c6a-ad44-4c9c502a0ca4@github.com>
Message-ID: <SgCHJ4_aAiGPXfJtmVmsPcxNQhP18GxWW4ex3_KPGlg=.0a34d839-b40e-4ae2-b6f4-6acbfc0b732a@github.com>

On Sun, 15 May 2022 18:36:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make the javadoc in the InputStream and OutputStream subclasses in core libs DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in client libs will be done another a separate bug.) When the time comes, will do any necessary merging for the changes in[JDK-8286200.
> 
> Please also review the CSR to cover the introduction of implspec and implNote tags: https://bugs.openjdk.java.net/browse/JDK-8286784

This pull request has now been integrated.

Changeset: 8e602b86
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e602b862db305e6f28b13f9fb0f7ff2cab89bae
Stats:     201 lines in 13 files changed: 60 ins; 45 del; 96 mod

8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8717

From jvernee at openjdk.java.net  Tue May 17 16:22:15 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 May 2022 16:22:15 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v4]
In-Reply-To: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
Message-ID: <GbAhk0daf2JAfvvOjtvTMipCgt7cnUIdojX5NIajn8U=.1ff1727b-8f40-4dd0-b1e6-e63d2b127e69@github.com>

> Hi,
> 
> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
> 
> Thanks,
> Jorn
> 
> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'pr/7959' into JEP-19-ASM
 - BootstrapMethodError -> ExceptionInInitializerError
 - Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change)
 - Fix LinkUpcall benchmark
 - 8286306: Upcall wrapper class sharing
   
   Reviewed-by: mcimadamore
 - Polish
 - 8281595: ASM-ify scope acquire/release for down call parameters
   8281387: Some downcall shapes show unexpected allocations
   
   Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
   Reviewed-by: mcimadamore
 - 8281228: Preview branch's CLinker.downcallHandle crashes inside asm
   
   Reviewed-by: sundar, jvernee
 - 8278414: Replace binding recipe customization using MH combinators with bytecode spinning
   
   Reviewed-by: mcimadamore
 - 8276648: Downcall stubs are never freed
   
   Reviewed-by: mcimadamore

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8685/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=03
  Stats: 2182 lines in 24 files changed: 1396 ins; 660 del; 126 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8685.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8685/head:pull/8685

PR: https://git.openjdk.java.net/jdk/pull/8685

From duke at openjdk.java.net  Tue May 17 16:58:49 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Tue, 17 May 2022 16:58:49 GMT
Subject: RFR: JDK-8281001 Examine the behavior of Class::forName if the
 caller is null
In-Reply-To: <l4dAZutgz4yucd8gLBaqi5fZuihA1ZoZckeoA3e1mjM=.e8c0380b-ba55-43d6-895f-7278c07f07ca@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
 <l4dAZutgz4yucd8gLBaqi5fZuihA1ZoZckeoA3e1mjM=.e8c0380b-ba55-43d6-895f-7278c07f07ca@github.com>
Message-ID: <oROa9s35y7vZerW3xzGlD5KBI9_MXN5eXY_8n2SB0EM=.629e9a2c-a629-4078-b52f-542f3578bcfe@github.com>

On Mon, 16 May 2022 18:55:42 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Class::forName(String)` javadoc should specify which class loader to use when invoked with null caller similar to the other APIs you fixed for null callers.
> 
> I think this new test case does not belong to `NullCallerGetResource.java` which is a test for `Module::getResource`. It's better to be placed under the `test/jdk/java/lang/Class/forName` directory that makes it clear it's a test for `Class::forName`.
> 
> Alternatively, we could move all the tests for null caller under a new clearly-named directory, maybe `test/jdk/jdk/nullCaller`. This may allow to do some refactoring and remove the duplicated code in these test cases. What do you think?

I like the idea of moving all the null caller tests to a clearly named directory to avoid duplication.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8711

From mchung at openjdk.java.net  Tue May 17 17:11:01 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 17 May 2022 17:11:01 GMT
Subject: RFR: JDK-8281001 Examine the behavior of Class::forName if the
 caller is null
In-Reply-To: <oROa9s35y7vZerW3xzGlD5KBI9_MXN5eXY_8n2SB0EM=.629e9a2c-a629-4078-b52f-542f3578bcfe@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
 <l4dAZutgz4yucd8gLBaqi5fZuihA1ZoZckeoA3e1mjM=.e8c0380b-ba55-43d6-895f-7278c07f07ca@github.com>
 <oROa9s35y7vZerW3xzGlD5KBI9_MXN5eXY_8n2SB0EM=.629e9a2c-a629-4078-b52f-542f3578bcfe@github.com>
Message-ID: <OD3bgoREKmLqssLTwrUYzJEPYCv60gpscVU6DlgOfnM=.a1dc8479-0575-4e27-a0c2-668cc97bfe04@github.com>

On Tue, 17 May 2022 16:55:14 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

> I like the idea of moving all the null caller tests to a clearly named directory to avoid duplication.

+1.   You can do this refactoring in a separate JBS issue and then update this PR when the tests are moved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8711

From alanb at openjdk.java.net  Tue May 17 17:14:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 17 May 2022 17:14:48 GMT
Subject: Integrated: 8286788: Test
 java/lang/Thread/virtual/ThreadAPI.testGetStackTrace3 fails
In-Reply-To: <usB7VoTJ_v6MfYT3ZtcSRqbQ2gkRC-di9NOoR5CzEaQ=.a61785dc-aebe-459f-aa19-d65f05d13ed5@github.com>
References: <usB7VoTJ_v6MfYT3ZtcSRqbQ2gkRC-di9NOoR5CzEaQ=.a61785dc-aebe-459f-aa19-d65f05d13ed5@github.com>
Message-ID: <_lQ_YeRfA7HwhOGYl17I7MkZ0Vs-KwvdwnWpfGfUS-A=.1790a3bc-a94d-4a50-8c32-f27717a6520c@github.com>

On Tue, 17 May 2022 11:15:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test fix. ThreadAPI.testGetStackTrace3 tests Thread::getStackTrace on a thread doing a selection operation. The test is not reliable as it expects to see the "select" method in the stack trace after waiting 200ms. The test is changed to poll the stack trace so that it's no longer dependent on sleep.
> 
> The update includes a drive-by change to the test description to use `@enablePreview`.

This pull request has now been integrated.

Changeset: 8535d51d
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8535d51db7e1c33218c4254e774de4ca4ca60023
Stats:     10 lines in 1 file changed: 3 ins; 2 del; 5 mod

8286788: Test java/lang/Thread/virtual/ThreadAPI.testGetStackTrace3 fails

Reviewed-by: darcy, jpai

-------------

PR: https://git.openjdk.java.net/jdk/pull/8743

From jbhateja at openjdk.java.net  Tue May 17 17:29:00 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 17 May 2022 17:29:00 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v6]
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <R1SR3YvaFnKIa_t2ChQK0AouGU8Jd390jtLT4nia2W0=.a98e797d-2153-403d-ac28-72555ef85529@github.com>

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8284960: Adding --enable-preview in vectorAPI benchmarks.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8425/files
  - new: https://git.openjdk.java.net/jdk/pull/8425/files/df7eb90e..0b7f84bb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=04-05

  Stats: 21 lines in 10 files changed: 7 ins; 4 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425

PR: https://git.openjdk.java.net/jdk/pull/8425

From bpb at openjdk.java.net  Tue May 17 18:10:58 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 17 May 2022 18:10:58 GMT
Subject: Integrated: 8213045: Add BigDecimal.TWO
In-Reply-To: <KEY7pcoz01lL7ePNaD9N7HTqCsde-QBVqkY7c6oJ7xE=.6b0623a6-a452-4212-ba4e-b45061ec4f52@github.com>
References: <KEY7pcoz01lL7ePNaD9N7HTqCsde-QBVqkY7c6oJ7xE=.6b0623a6-a452-4212-ba4e-b45061ec4f52@github.com>
Message-ID: <Q2QbS9pMR_9nx0z6DliBn59SYll1clFlQc8luSt_vm8=.010bd2d6-e4ea-417b-9d1c-fc513eedd714@github.com>

On Mon, 16 May 2022 21:29:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add constant `java.math.BigDecimal.TWO`.

This pull request has now been integrated.

Changeset: 1d8e92ae
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1d8e92ae0d2d0d6740e2171abef45545439e6414
Stats:     17 lines in 2 files changed: 12 ins; 2 del; 3 mod

8213045: Add BigDecimal.TWO

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/8735

From lancea at openjdk.java.net  Tue May 17 19:40:39 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 17 May 2022 19:40:39 GMT
Subject: RFR: 8282280: Update Xerces to Version 2.12.2 [v2]
In-Reply-To: <3y07XSVou7GU8asGFL6HZ99bhd-i87hMAOBD3yDdusQ=.336f474c-5317-4bcd-8ac2-281d7f30c2a4@github.com>
References: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
 <3y07XSVou7GU8asGFL6HZ99bhd-i87hMAOBD3yDdusQ=.336f474c-5317-4bcd-8ac2-281d7f30c2a4@github.com>
Message-ID: <M3AhgmxzHXRQlId1ZLL3kuOA8HQwDQuwYGhx74Y4NnY=.d525ddcb-2ba4-4022-995d-9ed1ee588ed7@github.com>

On Tue, 17 May 2022 00:39:37 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Update to Xerces 2.12.2.
>> 
>> The update also fixes JDK-8144117. Added a test.
>> 
>> Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this update. See related issue report.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   provider description

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8732

From duke at openjdk.java.net  Tue May 17 20:16:48 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Tue, 17 May 2022 20:16:48 GMT
Subject: RFR: JDK-8281001 Examine the behavior of Class::forName if the
 caller is null [v2]
In-Reply-To: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
Message-ID: <mZmtII2DwrYj6mcbUZQ3O7X3N0qXYMlyWSDRvX1ncgI=.4e4b6dec-6f71-4f24-9a19-ed047e576b1b@github.com>

> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  Added javadoc comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8711/files
  - new: https://git.openjdk.java.net/jdk/pull/8711/files/5b10f0d2..9d054ea6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8711&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8711&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

PR: https://git.openjdk.java.net/jdk/pull/8711

From naoto at openjdk.java.net  Tue May 17 20:48:55 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 17 May 2022 20:48:55 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable
In-Reply-To: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
Message-ID: <XzQM021bjWZolW_iQHJH5xDbIH3XKu1rvmlehAeOQWA=.48cb1180-d888-4e20-911f-2f23f544f0c7@github.com>

On Wed, 11 May 2022 18:00:31 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Thanks for contributing the fix. This issue has been reported in the past, but closed as will not fix (https://bugs.openjdk.java.net/browse/JDK-6992725), as implementing POSIX TZ fully requires a sizable amount of work for a rare situation. Returning a fixed offset ID with the `TZ` set to observing DST is thus a compromised solution. Even if the fix would return a custom zone observing the DST does not mean the zone is correct in winter. Having said that I agree that the derived fixed offset zone should reflect the *current* offset, as well as macOS's implementation.

src/java.base/unix/native/libjava/TimeZone_md.c line 609:

> 607:     }
> 608: 
> 609:     offset = (gmt.tm_hour - localtm.tm_hour)*3600 + (gmt.tm_min - localtm.tm_min)*60;

Since it is not using `timezone` anymore, we can reverse the subtraction, i.e., `localtime` - `gmtime` so that the weird sign switch below can be eliminated.

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 2:

> 1: /*
> 2:  * Copyright (c) 2001, 2022, Oracle and/or its affiliates. All rights reserved.

This is a new test case, the year should be only 2022.

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 27:

> 25:  * Specifically called by runCustomTzIDCheckDST.sh to check if Daylight savings is
> 26:  * properly followed with a custom TZ code set through environment variables.
> 27:  * */

Nit: Need a new line.

test/jdk/java/util/TimeZone/runCustomTzIDCheckDST.sh line 1:

> 1: #

I'd change this script into a java test case (using `.sh` is not recommended). In fact, this causes a failure invoking `javac` with `-Xmx768m` (from TESTVMOPTS)
There are libraries under `jdk/test/lib/` for building test jvm process and tools.

test/jdk/java/util/TimeZone/runCustomTzIDCheckDST.sh line 40:

> 38: 
> 39: OS=`uname -s`
> 40: case "$OS" in 

In case other than Linux/AIX, it would be helpful to emit some message that the test is ignored.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From kcr at openjdk.java.net  Tue May 17 22:55:44 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 17 May 2022 22:55:44 GMT
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe [v2]
In-Reply-To: <BtITAMIGuPEYwTYNhIHiSepf6tS1nr5Eu_BHGz1Zw14=.4c77c962-801f-419f-82e8-39971325961a@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <BtITAMIGuPEYwTYNhIHiSepf6tS1nr5Eu_BHGz1Zw14=.4c77c962-801f-419f-82e8-39971325961a@github.com>
Message-ID: <0n8TJdsNSrY4EdBkl-kMBH3kw5dxpMmBNESnw5xubD0=.0dbffd09-d82f-42b0-af90-9204d9472e05@github.com>

On Thu, 12 May 2022 04:15:50 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.
>>  - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles.
>>  - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error.
>>  - Added two tests to validate fix.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe [v2]

I'm just catching up with this thread. Based on the analysis, it's pretty clear that any solution that actually allows bundling native launchers is going to take more research, and is out of scope for this bug. Some combination of [JDK-8286850](https://bugs.openjdk.java.net/browse/JDK-8286850) and/or providing Java launchers that don't have an `Info.plist` is likely needed to provide a complete solution.

Given that, I think that this PR seems a reasonable fix to avoid creating an app bundle that can't be uploaded to the app store.

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/8666

From naoto at openjdk.java.net  Tue May 17 23:40:04 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 17 May 2022 23:40:04 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]
In-Reply-To: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
Message-ID: <h9BjimboAkIuIUbUrWAnFB-w0L6u98DeDWnSItdldnk=.a708fe0f-537a-4d75-93e2-d2d16257d047@github.com>

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

Naoto Sato 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 13 additional commits since the last revision:

 - Merge branch 'master' into JDK-8279185
 - Addressing review comments
 - Revert to use the default method
 - Removed unnecessary package names
 - Modified class desc of `IsoFields`
 - abstract class -> top level interface
 - interface -> abstract class
 - Removed the method
 - Changed to use a type to determine ISO based or not
 - Renamed the new method
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d7dfd3a6...3f69909f

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/45edbc3b..3f69909f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=08-09

  Stats: 243466 lines in 3650 files changed: 182993 ins; 40828 del; 19645 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

PR: https://git.openjdk.java.net/jdk/pull/7683

From joehw at openjdk.java.net  Wed May 18 00:07:59 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 18 May 2022 00:07:59 GMT
Subject: Integrated: 8282280: Update Xerces to Version 2.12.2
In-Reply-To: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
References: <3m9Wx6mtyPIETeAvTmxJvoz2lJDUsrtGNMup02w3vEA=.23476abf-fc2b-4614-8b49-88d620f32fa4@github.com>
Message-ID: <4PiJZIc_asQQLQZjq3yJ8MVTjEMbwT5mghqWo5mkeZg=.b4dd6621-b858-4d04-b9f2-1bc52994a47f@github.com>

On Mon, 16 May 2022 19:34:11 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Update to Xerces 2.12.2.
> 
> The update also fixes JDK-8144117. Added a test.
> 
> Tests: local XML tests passed. Tier2 passed. Two JCK tests failed with this update. See related issue report.

This pull request has now been integrated.

Changeset: 72bd41b8
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/72bd41b844e03da4bcb19c2cb38d96975a9ebceb
Stats:     310 lines in 17 files changed: 296 ins; 3 del; 11 mod

8282280: Update Xerces to Version 2.12.2

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/8732

From bchristi at openjdk.java.net  Wed May 18 00:16:44 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 18 May 2022 00:16:44 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v3]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <yzfXlOMbxbsWiGCH2cru8ltYoZWwR5JypVQX1AIcVxM=.58faad40-d5a6-4cec-922a-3b4d583d7f4a@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge
 - Rename inner class to EnumCtx ; use homeCtx() in AbstractLdapNamingEnumeration for consistencty ; new instance vars can be final
 - fix whitespace
 - Merge branch 'master' into remove-finalizers
 - Test changes to test new cleaner code
 - Rename test to LdapEnumeration
 - Create copy of AddNewEntry test to test AbstractLdapNamingEnumeration Cleaner
 - Merge branch 'master' into remove-finalizers
 - Replace AbstractLdapNamingEnumeration finalizer with Cleaner

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8311/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=02
  Stats: 262 lines in 7 files changed: 194 ins; 20 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

PR: https://git.openjdk.java.net/jdk/pull/8311

From itakiguchi at openjdk.java.net  Wed May 18 00:41:57 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Wed, 18 May 2022 00:41:57 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v2]
In-Reply-To: <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <5N2PpEbupu2OI_aP8hhwzdvw63Blf016AIOKpyIIDV0=.002669d1-143f-4059-a33f-3290e3b4d40c@github.com>
 <yeRoMjMnqiqQKPrO0HKcFIsEZFgkUs21y8tYEktmam0=.dfa7aeea-3a7d-46e8-83ba-23d17f719688@github.com>
Message-ID: <4rc07WcYaY3AeSEsHUjXqSDvRha4ngnV0dSvKNtYx8I=.444e56fe-4cbe-49a3-bfef-53039a8cdf3e@github.com>

On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
>
> Can you clarify the use of different charset properties for the ProcessEnvironment vs the CommandLine strings?
> 
> They are used to decode or encode strings in the APIs to native functions respectively.
> If I understand `native.encoding` was introduced to reflect the default encoding of file contents, while `sun.jnu.encoding` is used to encode filenames.
> 
> I think I would have expected to see `sun.jnu.encoding` to be used in all contexts when encoding/decoding strings to the native representations.  (Assuming its not required for backward compatibility).

Hello @RogerRiggs .
Do you have any comment ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From njian at openjdk.java.net  Wed May 18 01:34:50 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Wed, 18 May 2022 01:34:50 GMT
Subject: RFR: 8281712: [REDO] AArch64: Implement string_compare intrinsic
 in SVE
In-Reply-To: <AIlwVz2HVDY7zwTuwlmKin7TvRMZbVBF3GW1rzsO8dc=.2470558c-74c7-4ac9-86eb-db0cf028dbf9@github.com>
References: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>
 <AIlwVz2HVDY7zwTuwlmKin7TvRMZbVBF3GW1rzsO8dc=.2470558c-74c7-4ac9-86eb-db0cf028dbf9@github.com>
Message-ID: <KmjhddBT6omIpgMEw3NF8SYoF--1nIw2v7lSYbPmFqM=.60ee8477-a2b9-4f7d-8164-d7117c594dc8@github.com>

On Tue, 17 May 2022 08:37:52 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> LGTM!

Thank you, Nick!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8723

From njian at openjdk.java.net  Wed May 18 01:37:48 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Wed, 18 May 2022 01:37:48 GMT
Subject: Integrated: 8281712: [REDO] AArch64: Implement string_compare
 intrinsic in SVE
In-Reply-To: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>
References: <edWw12E-toKxXqwZKKDn1375C38oV_NJFbRebB6-3vE=.1d857773-a4de-40e4-9b2a-ce3e1ac8ea23@github.com>
Message-ID: <8Q5uhLsweukyIRxn1emxuU_TVweZAfHjaK2xed66h4M=.bb9ca325-ce0d-4d93-a5d7-6e9cebcb182a@github.com>

On Mon, 16 May 2022 07:21:27 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> This is the REDO of JDK-8269559 and JDK-8275448. Those two backouts finally turned to be some system zlib issue in AArch64 macOS, and is not related to the patch itself. See [1][2] for details.
> 
> This patch is generally the same as JDK-8275448, which uses SVE to optimize string_compare intrinsics for long string comparisons. I did a rebase with small tweaks to get better performance on recent Neoverse hardware. Test data on systems with different SVE vector sizes:
> 
> 
>    case    delta size  128-bits  256-bits  512-bits
> compareToLL  2   24     0.17%     0.58%     0.00%
> compareToLL  2   36     0.00%    2.25%      0.04%
> compareToLL  2   72     -4.40%   3.87%      -12.82%
> compareToLL  2   128    4.55%    58.31%     13.53%
> compareToLL  2   256    19.39%   69.77%     82.03%
> compareToLL  2   512    1.81%    68.38%     170.93%
> compareToLU  2   24     25.57%   46.98%     54.61%
> compareToLU  2   36     36.03%   70.26%     94.33%
> compareToLU  2   72     35.86%   90.58%     146.04%
> compareToLU  2   128    70.82%   119.19%    266.22%
> compareToLU  2   256    80.77%   146.33%    420.01%
> compareToLU  2   512    94.62%   171.72%    530.87%
> compareToUL  2   24     20.82%   34.48%     62.14%
> compareToUL  2   36     39.77%   60.79%     69.77%
> compareToUL  2   72     35.46%   84.34%     121.90%
> compareToUL  2   128    67.77%   110.97%    220.53%
> compareToUL  2   256    77.05%   160.29%    331.30%
> compareToUL  2   512    91.88%   184.57%    524.21%
> compareToUU  2   24     -0.13%   0.40%      0.00%
> compareToUU  2   36     -9.18%   12.84%     -13.93%
> compareToUU  2   72     1.67%    60.61%     6.69%
> compareToUU  2   128    13.51%   60.33%     55.27%
> compareToUU  2   256    2.55%    62.17%     153.26%
> compareToUU  2   512    4.12%    68.62%     201.68%
> 
> JTreg tests passed on SVE hardware.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8275448
> [2] https://bugs.openjdk.java.net/browse/JDK-8282954

This pull request has now been integrated.

Changeset: b5526e5e
Author:    Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b5526e5e5935658ed1d39938441ae1a3417c0545
Stats:     443 lines in 7 files changed: 433 ins; 0 del; 10 mod

8281712: [REDO] AArch64: Implement string_compare intrinsic in SVE

Co-authored-by: Tat Wai Chong <tatwai.chong at arm.com>
Reviewed-by: thartmann, ngasson

-------------

PR: https://git.openjdk.java.net/jdk/pull/8723

From mchung at openjdk.java.net  Wed May 18 02:06:45 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 18 May 2022 02:06:45 GMT
Subject: RFR: 8286858: Remove dead code in sun.reflect.misc.MethodUtil
In-Reply-To: <yNqsZAqSuObV3UY7t5A6Y97uP2qHF5wxmseBBCa4VQw=.f26b2841-fe20-4ba5-b491-dc98f7e75cd2@github.com>
References: <yNqsZAqSuObV3UY7t5A6Y97uP2qHF5wxmseBBCa4VQw=.f26b2841-fe20-4ba5-b491-dc98f7e75cd2@github.com>
Message-ID: <BOv7D8d_G7_7rAB85Cg_mS8tHjazW-cmvFdJU9xN7ic=.4cd10886-4dc5-4bf2-94ef-2094cc6ac836@github.com>

On Sun, 15 May 2022 12:47:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> They are unused and leftover since JDK 7.  It's good to remove them.

Looks good.   Do you know why there are test failures (they look unrelated)?

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8715

From jpai at openjdk.java.net  Wed May 18 02:53:49 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 18 May 2022 02:53:49 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v2]
In-Reply-To: <B3jOs2mD5UAbmSdS0IYbIu3qVb5dl5dBsWekJQT6OUU=.e0b461a2-bc82-4c57-aa7c-f8415a61dbef@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <B3jOs2mD5UAbmSdS0IYbIu3qVb5dl5dBsWekJQT6OUU=.e0b461a2-bc82-4c57-aa7c-f8415a61dbef@github.com>
Message-ID: <nrGBwA6vmG_fJoHfhXkK90t94mEseybWdkeYC5QAxiw=.109d7fb0-9fd8-4e11-a03e-b796c78d3e5e@github.com>

On Tue, 17 May 2022 13:08:32 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix of LimitedImage test

Hello Adam, I don't have necessary knowledge of this area, so I don't know what approach would be preferred.

But a couple of questions:

- If we do decide to add the `jdk.zipfs` dependency to `jdk.compiler` module, do you think the `LimitedImage` test is still relevant? Or should it be removed? The comment on that test states:
> @summary Verify javac behaves properly in absence of zip/jar FileSystemProvider

and it does so by using `--limit-modules`. But now with the `jdk.zipfs` being a dependency, the zip/jar FileSystemProvider will not be absent and the test then would seem unnecessary.

- In the JBS issue corresponding to this PR, you noted that:

>There are actually two different issues:
>
>First in JDKPlatformProvider, which silently swallows ProviderNotFoundException. 

Should something be done there? I see that the catch block happens to reside in the `static` block of that class (which also happens to be a implementation of a Java `service`), so I'm unsure what if anything can be done there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8747

From iris at openjdk.java.net  Wed May 18 02:58:53 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 02:58:53 GMT
Subject: RFR: 8286858: Remove dead code in sun.reflect.misc.MethodUtil
In-Reply-To: <yNqsZAqSuObV3UY7t5A6Y97uP2qHF5wxmseBBCa4VQw=.f26b2841-fe20-4ba5-b491-dc98f7e75cd2@github.com>
References: <yNqsZAqSuObV3UY7t5A6Y97uP2qHF5wxmseBBCa4VQw=.f26b2841-fe20-4ba5-b491-dc98f7e75cd2@github.com>
Message-ID: <EtuaAiU7HQ44E8C9UCsAHOonswM_jMFwWpi5y0oMc8A=.a89dcffa-da20-4545-9e59-2afa4cf27213@github.com>

On Sun, 15 May 2022 12:47:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> They are unused and leftover since JDK 7.  It's good to remove them.

Nice clean up.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8715

From dholmes at openjdk.java.net  Wed May 18 06:16:47 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 18 May 2022 06:16:47 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher [v2]
In-Reply-To: <kpwhZV6rm7YXl9P4Z7xAzqv87DzvP-emA7s0VjiPyqQ=.7c71f621-b2ac-402d-a4e3-271d89eb542f@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
 <kpwhZV6rm7YXl9P4Z7xAzqv87DzvP-emA7s0VjiPyqQ=.7c71f621-b2ac-402d-a4e3-271d89eb542f@github.com>
Message-ID: <KO3oQLmXdsYOLegou3KFY_r-abinD8FIS8VpobQV-GY=.bc69acbf-960e-4da2-92cd-6eea3e863e0c@github.com>

On Tue, 17 May 2022 13:55:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> GCC 12 reports as following:
>
> Yasumasa Suenaga 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:
> 
>  - Use assert() to check jargv
>  - Merge remote-tracking branch 'upstream/master' into JDK-8286694
>  - 8286694: Incorrect argument processing in java launcher

Looks fine to me.

Thanks.

Sorry I see what you mean, it is just an `assert(cond)` not `assert(cond, message)`, but that is fine.

src/java.base/share/native/libjli/java.c line 1631:

> 1629:         const char *arg = jargv[i];
> 1630:         if (arg[0] == '-' && arg[1] == 'J') {
> 1631:             assert(arg[2] != '\0' && "Invalid JAVA_ARGS or EXTRA_JAVA_ARGS defined by build");

Interesting trick.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8694

From dholmes at openjdk.java.net  Wed May 18 06:16:47 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 18 May 2022 06:16:47 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher
In-Reply-To: <77vg1jdikWjo9b08yeLPCjrvml1pbNnK7n14Tu4YHZg=.d2bb1356-1bde-46c8-9877-a57cb909fb66@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
 <yqxakAeLdUFdD1b3j4KiYqrZQOFp1Rm5qUxdBnsdDKs=.83a764c8-3664-4bba-a196-41070afd7fd8@github.com>
 <77vg1jdikWjo9b08yeLPCjrvml1pbNnK7n14Tu4YHZg=.d2bb1356-1bde-46c8-9877-a57cb909fb66@github.com>
Message-ID: <MNF8j84570KvFpi9-Xs85SBeaLSWT_6Y6bhXLHH4oQ8=.a0aae797-1ce2-457a-b7a4-4395af98909b@github.com>

On Tue, 17 May 2022 13:54:59 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> You forced me to look at this in depth. The values are set via the build system. In the build system it is impossible to get just -J because the -J is only added as a prefix for an existing string. So basically this is impossible code to reach unless you manually override the build system definition. So as far as I can see this is a classic case where we want an assert.
>> 
>> 
>> if (arg[0] == '-' && arg[1] == 'J') {
>>     assert(arg[2] != '\0', "Invalid JAVA_ARGS or EXTRA_JAVA_ARGS defined by build");
>>     *nargv++ = JLI_StringDup(arg + 2);
>> }
>
> @dholmes-ora Thanks for your comment!
> 
> We cannot use `assert(cond, message)` at here because it is not HotSpot code. In imageFile.cpp for libjimage. It uses `assert(cond && message)`, so I use this style in new commit, and the warning has gone.
> 
> I can change to "normal" `assert` usage at here if it is strange.

@YaSuenag I know this is not hotspot code. Please see existing use of assert in related code i.e. src/java.base/share/native/libjli/args.c

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From asotona at openjdk.java.net  Wed May 18 06:21:50 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 18 May 2022 06:21:50 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v2]
In-Reply-To: <nrGBwA6vmG_fJoHfhXkK90t94mEseybWdkeYC5QAxiw=.109d7fb0-9fd8-4e11-a03e-b796c78d3e5e@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <B3jOs2mD5UAbmSdS0IYbIu3qVb5dl5dBsWekJQT6OUU=.e0b461a2-bc82-4c57-aa7c-f8415a61dbef@github.com>
 <nrGBwA6vmG_fJoHfhXkK90t94mEseybWdkeYC5QAxiw=.109d7fb0-9fd8-4e11-a03e-b796c78d3e5e@github.com>
Message-ID: <MiDA9Krap0LjS2ZNIR74gSyyiAhB2FMD66uZfXt2yW8=.868bad95-6f9c-4c45-9862-ba3fe00dc166@github.com>

On Wed, 18 May 2022 02:50:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Adam, I don't have necessary knowledge of this area, so I don't know what approach would be preferred.
> 
> But a couple of questions:
> 
> * If we do decide to add the `jdk.zipfs` dependency to `jdk.compiler` module, do you think the `LimitedImage` test is still relevant? Or should it be removed? The comment on that test states:
> 
> > @summary Verify javac behaves properly in absence of zip/jar FileSystemProvider
> 
> and it does so by using `--limit-modules`. But now with the `jdk.zipfs` being a dependency, the zip/jar FileSystemProvider will not be absent and the test then would seem unnecessary.

You are right, the test description should change. The test name is LimitedImage and it verifies that javac behaves properly in limited JDK image. I think the purpose of the test is still the same, just results are different (now it pass compilation instead of failing with specific error).

Thanks for pointing it out.

> 
> * In the JBS issue corresponding to this PR, you noted that:
> 
> > There are actually two different issues:
> > First in JDKPlatformProvider, which silently swallows ProviderNotFoundException.
> 
> Should something be done there? I see that the catch block happens to reside in the `static` block of that class (which also happens to be a implementation of a Java `service`), so I'm unsure what if anything can be done there.

Silent swallow of an exception in static initializer of a service is not very good practice and it has significant effect on this issue right now. However it will express itself only in corner cases (like for example broken ct.sym file) after this patch is integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8747

From asotona at openjdk.java.net  Wed May 18 06:30:34 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 18 May 2022 06:30:34 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
Message-ID: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>

> ### Problem description
> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
> fails to run java source launcher correctly (for example when --source N is specified).
> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
> 
> ### Root cause
> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
> 
> ### Alternative patch
> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
> 
> ### Proposed fix
> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
> Plus added specific test case.
> 
> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  corrected LimitedImage test description

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8747/files
  - new: https://git.openjdk.java.net/jdk/pull/8747/files/6bdf4a9a..0e55575b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8747&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8747/head:pull/8747

PR: https://git.openjdk.java.net/jdk/pull/8747

From duke at openjdk.java.net  Wed May 18 06:56:57 2022
From: duke at openjdk.java.net (Shruthi)
Date: Wed, 18 May 2022 06:56:57 GMT
Subject: RFR: 8285097: Duplicate XML keys in XPATHErrorResources.java and
 XSLTErrorResources.java [v8]
In-Reply-To: <7WijoWduT9XKDeGodvpvNPHBAjeN5-SFW7nTf5Y9FBg=.5a1415e2-b3bb-4f4c-be86-41dbfb471169@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
 <ifRS0p09qyo3hmoBlQjHbhiq9LV2fIfwisYCWqv0cEA=.ada83606-3b2a-4156-b8dd-f3281fc993bc@github.com>
 <aMfswvEA0EQnTfacmC1VnUj5SwHvp3MCbLvinbYhSEM=.a8580a46-d246-4eef-a1f3-d7ea89b8a02e@github.com>
 <7WijoWduT9XKDeGodvpvNPHBAjeN5-SFW7nTf5Y9FBg=.5a1415e2-b3bb-4f4c-be86-41dbfb471169@github.com>
Message-ID: <W3ogrVV29W5LRu99AHqMnu45NtVP6lP1Qqs7EAeh5A8=.fa3840d3-9c6f-42a4-b915-093d8bc63993@github.com>

On Mon, 16 May 2022 18:27:23 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Do not enclose the skara command within backquotes.
>
>> Do not enclose the skara command within backquotes.
> 
> Thanks Naoto!  I didn't realize that's what he did :-)

@JoeWang-Java I have issued the **integrate** command. Now it is ready to be sponsored. Please do the needful

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From stuefe at openjdk.java.net  Wed May 18 07:43:49 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 18 May 2022 07:43:49 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher [v2]
In-Reply-To: <KO3oQLmXdsYOLegou3KFY_r-abinD8FIS8VpobQV-GY=.bc69acbf-960e-4da2-92cd-6eea3e863e0c@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
 <kpwhZV6rm7YXl9P4Z7xAzqv87DzvP-emA7s0VjiPyqQ=.7c71f621-b2ac-402d-a4e3-271d89eb542f@github.com>
 <KO3oQLmXdsYOLegou3KFY_r-abinD8FIS8VpobQV-GY=.bc69acbf-960e-4da2-92cd-6eea3e863e0c@github.com>
Message-ID: <6n3pXTWmtE13-EL9SCBy87FfjyHMI2pZ-_QV0hYCyuw=.3b70dfa7-0be1-4122-b571-45356f608117@github.com>

On Wed, 18 May 2022 06:12:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yasumasa Suenaga 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:
>> 
>>  - Use assert() to check jargv
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8286694
>>  - 8286694: Incorrect argument processing in java launcher
>
> src/java.base/share/native/libjli/java.c line 1631:
> 
>> 1629:         const char *arg = jargv[i];
>> 1630:         if (arg[0] == '-' && arg[1] == 'J') {
>> 1631:             assert(arg[2] != '\0' && "Invalid JAVA_ARGS or EXTRA_JAVA_ARGS defined by build");
> 
> Interesting trick.

Since we pass NDEBUG, this assert is disabled in release builds. This is the supposed behavior, right? That we don't do anything on release builds?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From duke at openjdk.java.net  Wed May 18 08:46:08 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 18 May 2022 08:46:08 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v4]
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <3DlU-JyFxA4D-e10Rh5qdEpsb3dbPMtfKrdqEHTbWkM=.a7ae971e-908c-495d-b7b4-8f833839fd7d@github.com>

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - 8282662: Revert ProxyGenerator
 - 8282662: Revert ProxyGenerator
 - 8282662: Revert dubious changes in MethodType
 - 8282662: Revert dubious changes
 - 8282662: Use List/Set.of() factory methods to save memory

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7729/files
  - new: https://git.openjdk.java.net/jdk/pull/7729/files/e765c42a..87c6623b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=02-03

  Stats: 575367 lines in 7617 files changed: 421069 ins; 87224 del; 67074 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7729.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729

PR: https://git.openjdk.java.net/jdk/pull/7729

From duke at openjdk.java.net  Wed May 18 08:46:09 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 18 May 2022 08:46:09 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v3]
In-Reply-To: <acEJ1Y7t06mvfzuypr1qxVatndsfmH6zXzYJk3yH_fM=.c8af8378-9d13-457c-aca5-c29345c31927@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <ILnjhQX_62AO-U6otaRb2ZtWqKSHafqfgI2fEoQVMCo=.ceeae264-50b8-4854-b3fe-a6d79dd8af50@github.com>
 <8Pt8f9db8jDyw_Val4ERLcUodzn2MR6Byx3cHFRerSQ=.0b210a6e-3e2e-477b-9828-c82e514b62b4@github.com>
 <FAz94giFgpWhvP92dNc3xetP7uZnL6HFvjm_HIx4-yc=.050146cc-fa6c-4290-a1f0-118bbc79e436@github.com>
 <8kThIsE5ikFJ_V3Y9ixYKlNcuMPg77ci974Q63wCH_Y=.69d3e25a-4091-4e9d-9da5-18054148744c@github.com>
 <lB5ub_ZJTwl8kSN6S7PBAa1FS66R68ztr_rIaMB3UAQ=.bf5d56f5-1efd-4a8f-8cdd-8dfb095fc647@github.com>
 <acEJ1Y7t06mvfzuypr1qxVatndsfmH6zXzYJk3yH_fM=.c8af8378-9d13-457c-aca5-c29345c31927@github.com>
Message-ID: <qwSjQ6LVg1pHfo3WfwbDflv0rF17KldAOWbopnr0498=.0e7e4af5-c5fa-472b-a8b4-18ea7970bf94@github.com>

On Mon, 16 May 2022 15:29:38 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> Even?in the?no?exceptions?case, the?`exceptionTypes`?array still?has to?be?allocated/copied by?`Method.getExceptionTypes()`[^1] when?the?`ProxyMethod`?constructor[^2] is?invoked.
>> 
>> So?if?anything, the?`List.of(?)`?call should?be?moved into?the?`ProxyMethod`?constructor.
>> And?maybe the?call to?`Method.getExceptionTypes()` should?be?changed to?`Method.getSharedExceptionTypes()`[^3].
>> 
>> [^1]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L340-L343
>> [^2]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java#L710-L714
>> [^3]: https://github.com/openjdk/jdk/blob/e765c42aa71a25a9c30f3409b8fdc6bda6f7b639/src/java.base/share/classes/java/lang/reflect/Method.java#L305-L308
>
>> So if anything, the List.of(?) call should be moved into the ProxyMethod constructor. And maybe the call to Method.getExceptionTypes() should be changed to Method.getSharedExceptionTypes()
> 
> Makes sense. Do you want me to do this within this PR (this would be a deviation from ticket's target), or it's better to create another one?

Ok, I've reverted `ProxyGenerator` and will include the changes into another PR

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From jvernee at openjdk.java.net  Wed May 18 09:53:31 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 09:53:31 GMT
Subject: Integrated: 8283689: Update the foreign linker VM implementation
In-Reply-To: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
References: <MsXd9_u3u96QBsrMwjiRKmiAUXjiWLMRsy1YU2OKXEo=.32cdaa67-21ab-4c43-8e31-651f13e14a16@github.com>
Message-ID: <96UqTMEdAdl4yleY0IBU6LJjL8ww23IUcktML7Aa8UM=.9bfa69dc-720b-43aa-9b77-147b29d925cd@github.com>

On Fri, 25 Mar 2022 13:48:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo.
> 
> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19.
> 
> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first.
> 
> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes:
> 
> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1].
> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed  [2], [3], [4], [5].
> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later).
> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9].
> 
> While the patch mostly consists of VM changes, there are also some Java changes to support (2).
> 
> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier.
> 
> Testing: Tier1-4
> 
> Thanks,
> Jorn
> 
> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358
> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49
> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3
> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3
> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120
> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a
> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062
> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f
> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9

This pull request has now been integrated.

Changeset: 81e4bdbe
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81e4bdbe1358b7feced08ba758ddb66415968036
Stats:     6914 lines in 155 files changed: 2577 ins; 3219 del; 1118 mod

8283689: Update the foreign linker VM implementation

Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Nick Gasson <ngasson at openjdk.org>
Reviewed-by: mcimadamore, vlivanov, rehn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7959

From duke at openjdk.java.net  Wed May 18 09:56:58 2022
From: duke at openjdk.java.net (openjdk-notifier[bot])
Date: Wed, 18 May 2022 09:56:58 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v4]
In-Reply-To: <GbAhk0daf2JAfvvOjtvTMipCgt7cnUIdojX5NIajn8U=.1ff1727b-8f40-4dd0-b1e6-e63d2b127e69@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <GbAhk0daf2JAfvvOjtvTMipCgt7cnUIdojX5NIajn8U=.1ff1727b-8f40-4dd0-b1e6-e63d2b127e69@github.com>
Message-ID: <tKhGyf7AU0M6MtvJxkwqZHT32HVgvN2xy1sSntfNGZY=.54aed4d0-4697-4ba5-8845-305fc2f73d7c@github.com>

On Tue, 17 May 2022 16:22:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'pr/7959' into JEP-19-ASM
>  - BootstrapMethodError -> ExceptionInInitializerError
>  - Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change)
>  - Fix LinkUpcall benchmark
>  - 8286306: Upcall wrapper class sharing
>    
>    Reviewed-by: mcimadamore
>  - Polish
>  - 8281595: ASM-ify scope acquire/release for down call parameters
>    8281387: Some downcall shapes show unexpected allocations
>    
>    Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
>    Reviewed-by: mcimadamore
>  - 8281228: Preview branch's CLinker.downcallHandle crashes inside asm
>    
>    Reviewed-by: sundar, jvernee
>  - 8278414: Replace binding recipe customization using MH combinators with bytecode spinning
>    
>    Reviewed-by: mcimadamore
>  - 8276648: Downcall stubs are never freed
>    
>    Reviewed-by: mcimadamore

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout JEP-19-ASM
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From dholmes at openjdk.java.net  Wed May 18 10:55:05 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 18 May 2022 10:55:05 GMT
Subject: RFR: 8286694: Incorrect argument processing in java launcher [v2]
In-Reply-To: <6n3pXTWmtE13-EL9SCBy87FfjyHMI2pZ-_QV0hYCyuw=.3b70dfa7-0be1-4122-b571-45356f608117@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
 <kpwhZV6rm7YXl9P4Z7xAzqv87DzvP-emA7s0VjiPyqQ=.7c71f621-b2ac-402d-a4e3-271d89eb542f@github.com>
 <KO3oQLmXdsYOLegou3KFY_r-abinD8FIS8VpobQV-GY=.bc69acbf-960e-4da2-92cd-6eea3e863e0c@github.com>
 <6n3pXTWmtE13-EL9SCBy87FfjyHMI2pZ-_QV0hYCyuw=.3b70dfa7-0be1-4122-b571-45356f608117@github.com>
Message-ID: <9FL69Le3Ec4hNb_lHu3z98anX2YwjH5kcBJXRb9sBho=.0a0d0acf-0317-4d93-afe3-ba92c3e5683e@github.com>

On Wed, 18 May 2022 07:40:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 1631:
>> 
>>> 1629:         const char *arg = jargv[i];
>>> 1630:         if (arg[0] == '-' && arg[1] == 'J') {
>>> 1631:             assert(arg[2] != '\0' && "Invalid JAVA_ARGS or EXTRA_JAVA_ARGS defined by build");
>> 
>> Interesting trick.
>
> Since we pass NDEBUG, this assert is disabled in release builds. This is the supposed behavior, right? That we don't do anything on release builds?

Right - that is what I would expect from an assert.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From shade at openjdk.java.net  Wed May 18 11:17:37 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 18 May 2022 11:17:37 GMT
Subject: RFR: 8286956: Loom: Define test groups for development/porting use
Message-ID: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>

It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work.

https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125

I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break.

Additional testing:
 - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom`
 - [ ] Linux AArch64 fastdebug `hotspot_loom jdk_loom`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/8765/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8765&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286956
  Stats: 28 lines in 2 files changed: 28 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8765.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8765/head:pull/8765

PR: https://git.openjdk.java.net/jdk/pull/8765

From jvernee at openjdk.java.net  Wed May 18 11:27:24 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 11:27:24 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v5]
In-Reply-To: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
Message-ID: <tjMWFm4IrX2RAoLSIArEKN5JqG-q1EM9Jyswq8JR6LU=.30a94102-4041-4b18-8cfa-235d0e68d2f1@github.com>

> Hi,
> 
> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
> 
> Thanks,
> Jorn
> 
> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 118 commits:

 - Merge branch 'JEP-19-ASM' of https://github.com/JornVernee/jdk into JEP-19-ASM
 - Merge branch 'pr/7959' into JEP-19-ASM
 - Merge branch 'master' into JEP-19-VM-IMPL2
 - ifdef NOT_PRODUCT -> ifndef PRODUCT
 - Missing ASSERT -> NOT_PRODUCT
 - Cleanup UL usage
 - Fix failure with SPEC disabled (accidentally dropped change)
 - indentation
 - fix space
 - Merge branch 'master' into JEP-19-ASM
 - ... and 108 more: https://git.openjdk.java.net/jdk/compare/81e4bdbe...ce5c677a

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8685/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=04
  Stats: 2142 lines in 24 files changed: 1357 ins; 660 del; 125 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8685.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8685/head:pull/8685

PR: https://git.openjdk.java.net/jdk/pull/8685

From jvernee at openjdk.java.net  Wed May 18 11:27:26 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 11:27:26 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <4HyW0Kv4vN-7wXdlxTzXFer1oLP6e2w_Z3XlxZT5w00=.f066b4a6-e471-43a3-873c-d5d6db9cbb95@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com>
 <4HyW0Kv4vN-7wXdlxTzXFer1oLP6e2w_Z3XlxZT5w00=.f066b4a6-e471-43a3-873c-d5d6db9cbb95@github.com>
Message-ID: <k9Z01wLRZ1cjeSykmVog4sOplnAUnSFgE7T0C2GdpLA=.dc3d2d9e-16d0-474c-af5f-347f6bf53d86@github.com>

On Tue, 17 May 2022 10:08:00 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 131:
>> 
>>> 129:     private int[] scopeSlots;
>>> 130:     private int curScopeLocalIdx = -1;
>>> 131:     private int RETURN_ALLOCATOR_IDX = -1;
>> 
>> These are not constants, so it is odd to see the name capitalized
>
> Right, habit of writing lambda forms, where name variables are capitalized.

Changed to lowercase.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From jvernee at openjdk.java.net  Wed May 18 11:27:29 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 11:27:29 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <I0bL2XkzvVdR-1FliPNBSnffI6_RURkgZUWRpon57EI=.0bccda3d-d1d3-40d1-aa03-80f7e2235628@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <I0bL2XkzvVdR-1FliPNBSnffI6_RURkgZUWRpon57EI=.0bccda3d-d1d3-40d1-aa03-80f7e2235628@github.com>
Message-ID: <N-ZOJrwh0nuAo2U8U7yxhEwnluRjiEeDWm-C6_7JBeA=.cd17bae6-a6c9-46fc-b3f9-dbcb756c1bbf@github.com>

On Tue, 17 May 2022 06:00:37 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootstrapMethodError -> ExceptionInInitializerError
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 157:
> 
>> 155:     }
>> 156: 
>> 157:     static MethodHandle doSpecialize(MethodHandle leafHandle, CallingSequence callingSequence, ABIDescriptor abi) {
> 
> I think thise method should be split in to, one version for the upcall, one for the downcall, i do not see the point of merging the two codes.

I've split this method into a specializeDowncall and specializeUpcall method.

> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 816:
> 
>> 814:             return;
>> 815:         }
>> 816:         if (con instanceof Integer) {
> 
> those can use the instanceof + type pattern

Done

> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 967:
> 
>> 965: 
>> 966:     // unaligned constants
>> 967:     public final static ValueLayout.OfBoolean JAVA_BOOLEAN_UNALIGNED = JAVA_BOOLEAN;
> 
> as far as i understand, those constants are accessed from the bytecode, they should be in their own class to cleanly separate the specializer part and the runtime part.

I've put these in a nest `Runtime` class, with a comment explaining that they are referenced from the generated code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From jvernee at openjdk.java.net  Wed May 18 11:27:31 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 11:27:31 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com>
Message-ID: <WSWzMwK-S9uqtbR2DMc5adtSYpTmmkJhqYo5WsGZmKM=.17c0bb8e-a6a8-40ef-a1cb-c307eb62dd99@github.com>

On Tue, 17 May 2022 08:41:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   BootstrapMethodError -> ExceptionInInitializerError
>
> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 291:
> 
>> 289:             emitGetStatic(Binding.Context.class, "DUMMY", BINDING_CONTEXT_DESC);
>> 290:         } else {
>> 291:             emitInvokeStatic(Binding.Context.class, "ofSession", OF_SESSION_DESC);
> 
> Maybe this is micro-optimization, but I realized that in reality we probably don't need any scope/session if there are no "ToSegment" bindings.

Done

> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 336:
> 
>> 334: 
>> 335:             if (callingSequence.forUpcall()) {
>> 336:                 // for upcalls, recipes have a result, which we handle here
> 
> I find this part a bit confusing. The comment speaks about recipes input and outputs, hinting at the fact that downcall bindings have inputs, while upcall bindings have outputs.
> In reality, if we look at the bindings themselves, they look pretty symmetric:
> 
> * UNBOX_ADDRESS = pops an Addressable and push a long on the stack
> * BOX_ADDRESS = pops a long and push a MemoryAddress on the stack
> 
> That is, in both cases it appears we have an input and an output (and the binding is just the function which maps one into another).
> 
> I think the input/output asymmetry comes in when we consider the full recipes. In downcalls, for a given argument we will have the following sequence:
> 
> Binding0, Binding1, ... BindingN-1, VMStore
> 
> While for upcalls we will have:
> 
> VMLoad, Binding1, Binding2, ... BindingN
> 
> So (ignoring return buffer for simplicity), for downcalls, it is obvious that before we can execute Binding0, we need some kind of "input value" (e.g. the value of some local). For upcalls, this is not needed, as the VMLoad binding will basically do that for free.
> When we finished executing the bindings, again, for downcalls there's nothing to do, as the chain always ends with a VMStore (which stores binding result into some local), while for upcalls we do need to set the output value explicitly.
> 
> In other words, it seems to me that having VMLoad and VMStore in the chains of bindings to be interpreted/specialized does more harm than good here. These low level bindings make sense for the VM code, as the VM needs to know how to load a value from a register, or how to store a value into a register. But in terms of the specializing Java code, these bindings are immaterial. At the same time, the fact that we have these bindings, and that they are virtualized, makes the code hard to follow, as some preparation happens in `BindingSpecializer::specialize`, while some other preparation happens inside `BindingSpecializer::doBindings`, as part of the virtualized impl of VMLoad/VMStore. And, this virtualized implementation ends up doing similar steps as what the preparation code before/after the binding execution does (e.g. for downcalls/VMStore we call setOutput, while for upcalls/VMLoad we call getInput).
> 
> All I'm saying here is that, for bindings to work, we _always_ need to call both getInput and setOutput - but it is easy to overlook this when looking at the code, because the getInput/setOutput calls are spread across two different places in the specializing code, perhaps making things more asymmetric than they need to be. (I realize I'm simplifying here, and that some details of the return buffer are not 100% quite as symmetric).

I'm not sure if there is anything actionable here?

I've thought in the past that it might be nice to have `GetArgument`/`SetArgument` and `GetReturnValue`/`SetReturnValue` binding operators as well, to make the inputs/outputs more explicit in the recipe. But, it doesn't seem like that would make things _much_ better...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From jvernee at openjdk.java.net  Wed May 18 11:27:31 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 11:27:31 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <unIxDAPY0Fqrh5qJuZEECdzi8GFmpCfmGBB5FyadpX4=.642cd620-6d5e-4784-87b9-f14db8e4ab9e@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <udsXg4-e5WD1mj5ygDb3WpMEgvaM662QY-2CWt-DiVM=.da9c4691-6e39-41a8-86c1-0f7e1a70cba6@github.com>
 <unIxDAPY0Fqrh5qJuZEECdzi8GFmpCfmGBB5FyadpX4=.642cd620-6d5e-4784-87b9-f14db8e4ab9e@github.com>
Message-ID: <Dd3JhAHZ9mI23dmQkC8Ux81vmypKJZVPsbflh2cQ-w4=.3e0cd14b-7a68-4507-826b-4cc7e3b8841c@github.com>

On Tue, 17 May 2022 11:18:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 943:
>> 
>>> 941:         Z, B, S, C, I, J, F, D, L;
>>> 942: 
>>> 943:         static BasicType of(Class<?> cls) {
>> 
>> This seems a duplication of ASM Type class for no good reason, Type.getOpcode(ILOAD) or Type.getOpcode(IRETURN) gives you the proper variant opcode
>
> Didn't know about that. Neat!

Removed the `BasicType` enum, switched to using `Type` and `Type.getSort()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From jvernee at openjdk.java.net  Wed May 18 11:27:32 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 11:27:32 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v2]
In-Reply-To: <htVlkP1pXKFYlm3-1_cmxGosRoNGQyX4OJRjoS7HS1c=.39150fb5-d9b8-4691-a7f1-20fb6a7bb827@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com>
 <KfYdkZDAFAIhEmiKt5koncrp07nvotIKoHVYgYWB1Nw=.5dd1fa87-91bd-40fb-abea-d5262549e328@github.com>
 <htVlkP1pXKFYlm3-1_cmxGosRoNGQyX4OJRjoS7HS1c=.39150fb5-d9b8-4691-a7f1-20fb6a7bb827@github.com>
Message-ID: <4_AWyEgqDZdWB7_m3BFbGgPAhmUdQ_JIOPbr9aWMixw=.4fc4165e-1484-45fb-82d5-a35ba7d83e17@github.com>

On Tue, 17 May 2022 10:19:04 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequence.java line 109:
>> 
>>> 107:      * @return the caller method type.
>>> 108:      */
>>> 109:     public MethodType callerMethodType() {
>> 
>> Would it make sense to either rename these, or to point to the fact that these are equivalent to Linker::downcallType/upcallType ?
>
> I don't think renaming them to down/upcallType makes sense, since both down/up calls use both the caller and callee method type. There can also be things that make these not equivalent to downcallType/upcallType, such as the SysV need to pass the number of floating point arguments for variadic calls as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java#L109-L111

I've left this as is for now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From zjx001202 at gmail.com  Wed May 18 12:07:05 2022
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 18 May 2022 20:07:05 +0800
Subject: Question: Is it possible to introduce ASCII coder for compact strings
 to optimize performance for ASCII compatible encoding?
Message-ID: <CAJL5A3==dUzrHZoa6s=5rjmRrXvY0xM2Y8JRvChSco40qkVmRw@mail.gmail.com>

After the introduction of compact strings in Java 9, the current String may
store byte arrays encoded as Latin1 or UTF-16.
Here's a troublesome thing: Latin1 is not compatible with UTF-8. Not all
Latin1 byte strings are legal UTF-8 byte strings:
They are only compatible within the ASCII range, when there are code points
greater than 127, Latin1 uses a one-byte
representation, while UTF-8 requires two bytes.

As an example, every time `JavaLangAccess::getBytesNoRepl` is called to
convert a string to a UTF-8 array,
the internal implementation needs to call `StringCoding.hasNegatives` to
scan the content byte array to determine that
the string can be encoded in ASCII, and thus eliminate array copies.
Similar steps are performed when calling `str.getBytes(UTF_8)`.

So, is it possible to introduce a third possible value for `String::coder`:
ASCII?
This looks like an attractive option, and if we do this, we can introduce
fast paths for many methods.

Of course, I know that this change is not completely free, and some methods
may bring slight performance
degradation due to the need to judge the coder, in particular, there may be
an impact on the performance of the
StringBuilder/StringBuffer. However, given that UTF-8 is by far the most
commonly used file encoding, the performance
benefits of fast paths are likely to cover more scenarios. In addition to
this, other ASCII compatible encodings may
also benefit, such as GB18030(GBK), or ISO 8859 variants. And if frozen
arrays were introduced into the JDK,
there would be more scenarios to enjoy performance improvements.

So I would like to ask, is it possible for JDK to improve String storage in
a similar way in the future?
Has anyone explored this issue before?

Sorry to bother you all, but I'm very much looking forward to the answer to
this question.

From alanb at openjdk.java.net  Wed May 18 12:23:49 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 18 May 2022 12:23:49 GMT
Subject: RFR: 8286956: Loom: Define test groups for development/porting use
In-Reply-To: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
References: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
Message-ID: <QR9KoIwLp1U7nWjACwCyo3VrLaTmlU6Af-9SnZ3LSVM=.6d698949-95ac-4759-84be-dc5631bf641b@github.com>

On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work.
> 
> https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
> https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125
> 
> I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom`
>  - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom`

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8765

From aivanov at openjdk.java.net  Wed May 18 13:34:24 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 13:34:24 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
Message-ID: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

Also, I fixed a couple of spelling mistakes.

-------------

Commit messages:
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...c7e73658

Changes: https://git.openjdk.java.net/jdk/pull/8768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284191
  Stats: 202 lines in 162 files changed: 0 ins; 11 del; 191 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From jvernee at openjdk.java.net  Wed May 18 13:37:59 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 13:37:59 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v5]
In-Reply-To: <tjMWFm4IrX2RAoLSIArEKN5JqG-q1EM9Jyswq8JR6LU=.30a94102-4041-4b18-8cfa-235d0e68d2f1@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <tjMWFm4IrX2RAoLSIArEKN5JqG-q1EM9Jyswq8JR6LU=.30a94102-4041-4b18-8cfa-235d0e68d2f1@github.com>
Message-ID: <4wEDBYrAp2-fKxMHbnM06x28_Uq1KTQW5UMQSlSw3Jk=.fe10ad78-73ae-4f8d-9f83-c061a68e30b1@github.com>

On Wed, 18 May 2022 11:27:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 118 commits:
> 
>  - Merge branch 'JEP-19-ASM' of https://github.com/JornVernee/jdk into JEP-19-ASM
>  - Merge branch 'pr/7959' into JEP-19-ASM
>  - Merge branch 'master' into JEP-19-VM-IMPL2
>  - ifdef NOT_PRODUCT -> ifndef PRODUCT
>  - Missing ASSERT -> NOT_PRODUCT
>  - Cleanup UL usage
>  - Fix failure with SPEC disabled (accidentally dropped change)
>  - indentation
>  - fix space
>  - Merge branch 'master' into JEP-19-ASM
>  - ... and 108 more: https://git.openjdk.java.net/jdk/compare/81e4bdbe...ce5c677a

I think I've addressed most review comments now. Please take another look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From forax at openjdk.java.net  Wed May 18 13:57:55 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 18 May 2022 13:57:55 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v5]
In-Reply-To: <tjMWFm4IrX2RAoLSIArEKN5JqG-q1EM9Jyswq8JR6LU=.30a94102-4041-4b18-8cfa-235d0e68d2f1@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <tjMWFm4IrX2RAoLSIArEKN5JqG-q1EM9Jyswq8JR6LU=.30a94102-4041-4b18-8cfa-235d0e68d2f1@github.com>
Message-ID: <2jc-7Db8s6I1EpSD8hCcjirMA49Mv_d2Qh0yQ1upsCM=.26508852-5649-4a90-b171-62f173f40400@github.com>

On Wed, 18 May 2022 11:27:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 118 commits:
> 
>  - Merge branch 'JEP-19-ASM' of https://github.com/JornVernee/jdk into JEP-19-ASM
>  - Merge branch 'pr/7959' into JEP-19-ASM
>  - Merge branch 'master' into JEP-19-VM-IMPL2
>  - ifdef NOT_PRODUCT -> ifndef PRODUCT
>  - Missing ASSERT -> NOT_PRODUCT
>  - Cleanup UL usage
>  - Fix failure with SPEC disabled (accidentally dropped change)
>  - indentation
>  - fix space
>  - Merge branch 'master' into JEP-19-ASM
>  - ... and 108 more: https://git.openjdk.java.net/jdk/compare/81e4bdbe...ce5c677a

LGTM !

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From aivanov at openjdk.java.net  Wed May 18 14:06:14 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 14:06:14 GMT
Subject: RFR: 8284213: Replace usages of 'a the' in xml
Message-ID: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

I tried to avoid changing external libraries, there are quite a few such typos.
Let me know if I should revert any files.

-------------

Commit messages:
 - 8284213: Replace usages of 'the a' in xml
 - 8284213: Replace usages of 'the the' in xml
 - 8284213: Replace usages of 'the the' in xml
 - 8284213: Replace usages of 'the the' in xml
 - 8284213: Replace usages of 'an? an?' in xml

Changes: https://git.openjdk.java.net/jdk/pull/8769/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8769&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284213
  Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8769.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8769/head:pull/8769

PR: https://git.openjdk.java.net/jdk/pull/8769

From mcimadamore at openjdk.java.net  Wed May 18 14:25:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 18 May 2022 14:25:46 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <WSWzMwK-S9uqtbR2DMc5adtSYpTmmkJhqYo5WsGZmKM=.17c0bb8e-a6a8-40ef-a1cb-c307eb62dd99@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com>
 <WSWzMwK-S9uqtbR2DMc5adtSYpTmmkJhqYo5WsGZmKM=.17c0bb8e-a6a8-40ef-a1cb-c307eb62dd99@github.com>
Message-ID: <ITgfGXeM7N9eezcUy6oOZJLOpg4iT0XoRC_MuS213kA=.e40677a8-a49f-477f-981e-83253c826e5c@github.com>

On Wed, 18 May 2022 11:23:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 336:
>> 
>>> 334: 
>>> 335:             if (callingSequence.forUpcall()) {
>>> 336:                 // for upcalls, recipes have a result, which we handle here
>> 
>> I find this part a bit confusing. The comment speaks about recipes input and outputs, hinting at the fact that downcall bindings have inputs, while upcall bindings have outputs.
>> In reality, if we look at the bindings themselves, they look pretty symmetric:
>> 
>> * UNBOX_ADDRESS = pops an Addressable and push a long on the stack
>> * BOX_ADDRESS = pops a long and push a MemoryAddress on the stack
>> 
>> That is, in both cases it appears we have an input and an output (and the binding is just the function which maps one into another).
>> 
>> I think the input/output asymmetry comes in when we consider the full recipes. In downcalls, for a given argument we will have the following sequence:
>> 
>> Binding0, Binding1, ... BindingN-1, VMStore
>> 
>> While for upcalls we will have:
>> 
>> VMLoad, Binding1, Binding2, ... BindingN
>> 
>> So (ignoring return buffer for simplicity), for downcalls, it is obvious that before we can execute Binding0, we need some kind of "input value" (e.g. the value of some local). For upcalls, this is not needed, as the VMLoad binding will basically do that for free.
>> When we finished executing the bindings, again, for downcalls there's nothing to do, as the chain always ends with a VMStore (which stores binding result into some local), while for upcalls we do need to set the output value explicitly.
>> 
>> In other words, it seems to me that having VMLoad and VMStore in the chains of bindings to be interpreted/specialized does more harm than good here. These low level bindings make sense for the VM code, as the VM needs to know how to load a value from a register, or how to store a value into a register. But in terms of the specializing Java code, these bindings are immaterial. At the same time, the fact that we have these bindings, and that they are virtualized, makes the code hard to follow, as some preparation happens in `BindingSpecializer::specialize`, while some other preparation happens inside `BindingSpecializer::doBindings`, as part of the virtualized impl of VMLoad/VMStore. And, this virtualized implementation ends up doing similar steps as what the preparation code before/after the binding execution does (e.g. for downcalls/VMStore we call setOutput, while for upcalls/VMLoad we call getInput).
>> 
>> All I'm saying here is that, for bindings to work, we _always_ need to call both getInput and setOutput - but it is easy to overlook this when looking at the code, because the getInput/setOutput calls are spread across two different places in the specializing code, perhaps making things more asymmetric than they need to be. (I realize I'm simplifying here, and that some details of the return buffer are not 100% quite as symmetric).
>
> I'm not sure if there is anything actionable here?
> 
> I've thought in the past that it might be nice to have `GetArgument`/`SetArgument` and `GetReturnValue`/`SetReturnValue` binding operators as well, to make the inputs/outputs more explicit in the recipe. But, it doesn't seem like that would make things _much_ better...

I wasn't suggesting to add more bindings. I was more suggesting to filter out the load/store from the set of bindings (since these are virtualized anyways) that are passed to `doBindings`. Then, before executing a set of bindings, (if we are in downcall mode) we load the corresponding input local var. After executing bindings (if we are in upcall mode) we store result in corresponding var.

E.g. make the logic that load locals and store locals explicit in the `specialize` method, rather than have parts of it execute "in  disguise" as "binding interpretation".

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From lancea at openjdk.java.net  Wed May 18 14:42:53 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:42:53 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <DOokHH_SxPtXjdpCSV9F_RmnHaNC6WnO3ChzhQNGxF8=.3fbb1072-bae7-4dc9-a424-4e9dd0cecc33@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From claes.redestad at oracle.com  Wed May 18 14:46:40 2022
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 18 May 2022 16:46:40 +0200
Subject: Question: Is it possible to introduce ASCII coder for compact
 strings to optimize performance for ASCII compatible encoding?
In-Reply-To: <CAJL5A3==dUzrHZoa6s=5rjmRrXvY0xM2Y8JRvChSco40qkVmRw@mail.gmail.com>
References: <CAJL5A3==dUzrHZoa6s=5rjmRrXvY0xM2Y8JRvChSco40qkVmRw@mail.gmail.com>
Message-ID: <7e6c09aa-aa5b-0582-2090-614911a05fdc@oracle.com>

Hi,

so your suggestion is that String::coder would be ASCII if all
codepoints are 0-127, then LATIN1 if it contains at least one char in
the 128-255 range, otherwise UTF16? As you say this would mean we could
skip scanning StringCoding::hasNegatives scans and similar overheads
when converting known-to-be-ASCII Strings to UTF-8 and other ASCII
compatible encoding. But it might also complicate logic in various
places, so we need a clear win to motivate such work.

So the first question to answer might be how much does the hasNegatives
calls cost us. Depending on your hardware (and JDK version) the answer
might be "almost nothing"!

I did some work last year to speed up encoding and decoding ASCII-only
data to/from various encodings. When I was done there was no longer much
of a difference when encoding from String to an ASCII-compatible charset
[1]. Maybe a scaling ~10% advantage for latin-1 in some microbenchmark
when decoding on really large strings[2].

But with the suggested change the decoding advantage would likely
disappear: we maintain the invariant that Strings are equals if and only
if their coders are equal, so no we'd now have to scan latin-1 encoded 
streams for non-ASCII bytes to disambiguate between ASCII and LATIN1.

Maybe there are some other case that would be helped, but with some
likely negatives and only a modest potential win then my gut feeling is
that this wouldn't pay off.

Best regards
Claes

[1] https://cl4es.github.io/2021/10/17/Faster-Charset-Encoding.html
[2] https://cl4es.github.io/2021/02/23/Faster-Charset-Decoding.html

(All the improvements discussed in the blog entires should be available 
since 17.0.2.)

On 2022-05-18 14:07, Glavo wrote:
> After the introduction of compact strings in Java 9, the current String may
> store byte arrays encoded as Latin1 or UTF-16.
> Here's a troublesome thing: Latin1 is not compatible with UTF-8. Not all
> Latin1 byte strings are legal UTF-8 byte strings:
> They are only compatible within the ASCII range, when there are code points
> greater than 127, Latin1 uses a one-byte
> representation, while UTF-8 requires two bytes.
> 
> As an example, every time `JavaLangAccess::getBytesNoRepl` is called to
> convert a string to a UTF-8 array,
> the internal implementation needs to call `StringCoding.hasNegatives` to
> scan the content byte array to determine that
> the string can be encoded in ASCII, and thus eliminate array copies.
> Similar steps are performed when calling `str.getBytes(UTF_8)`.
> 
> So, is it possible to introduce a third possible value for `String::coder`:
> ASCII?
> This looks like an attractive option, and if we do this, we can introduce
> fast paths for many methods.
> 
> Of course, I know that this change is not completely free, and some methods
> may bring slight performance
> degradation due to the need to judge the coder, in particular, there may be
> an impact on the performance of the
> StringBuilder/StringBuffer. However, given that UTF-8 is by far the most
> commonly used file encoding, the performance
> benefits of fast paths are likely to cover more scenarios. In addition to
> this, other ASCII compatible encodings may
> also benefit, such as GB18030(GBK), or ISO 8859 variants. And if frozen
> arrays were introduced into the JDK,
> there would be more scenarios to enjoy performance improvements.
> 
> So I would like to ask, is it possible for JDK to improve String storage in
> a similar way in the future?
> Has anyone explored this issue before?
> 
> Sorry to bother you all, but I'm very much looking forward to the answer to
> this question.

From lancea at openjdk.java.net  Wed May 18 14:47:56 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:47:56 GMT
Subject: RFR: 8284213: Replace usages of 'a the' in xml
In-Reply-To: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
References: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
Message-ID: <84WIsg1mRZYleHRSABqIypeQmbgGl-TOSdX8qnbKFIE=.0f21a12c-ac80-4473-9d23-2d4d3d24f822@github.com>

On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I tried to avoid changing external libraries, there are quite a few such typos.
> Let me know if I should revert any files.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8769

From duke at openjdk.java.net  Wed May 18 14:48:16 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 18 May 2022 14:48:16 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v5]
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <DJ0XaRq4hIR0XUakp9iieiNFVzFgzawXT9l5oZ7nFBY=.43fe1516-af2a-45b8-965e-697019bb9fe6@github.com>

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - 8282662: Revert wrong copyright year change
 - 8282662: Revert ProxyGenerator
 - 8282662: Revert ProxyGenerator
 - 8282662: Revert dubious changes in MethodType
 - 8282662: Revert dubious changes
 - 8282662: Use List/Set.of() factory methods to save memory

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7729/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=04
  Stats: 12 lines in 4 files changed: 1 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7729.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729

PR: https://git.openjdk.java.net/jdk/pull/7729

From aivanov at openjdk.java.net  Wed May 18 14:53:28 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 14:53:28 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
Message-ID: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

It's the last issue in the series, and it still touches different areas of the code.

-------------

Commit messages:
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'an? an?' in source code
 - 8284209: Replace remaining usages of 'a the' in source code
 - 8284209: Replace remaining usages of 'an the' in source code
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...8290c07e

Changes: https://git.openjdk.java.net/jdk/pull/8771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284209
  Stats: 51 lines in 41 files changed: 0 ins; 2 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From jvernee at openjdk.java.net  Wed May 18 14:55:00 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 14:55:00 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <ITgfGXeM7N9eezcUy6oOZJLOpg4iT0XoRC_MuS213kA=.e40677a8-a49f-477f-981e-83253c826e5c@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com>
 <WSWzMwK-S9uqtbR2DMc5adtSYpTmmkJhqYo5WsGZmKM=.17c0bb8e-a6a8-40ef-a1cb-c307eb62dd99@github.com>
 <ITgfGXeM7N9eezcUy6oOZJLOpg4iT0XoRC_MuS213kA=.e40677a8-a49f-477f-981e-83253c826e5c@github.com>
Message-ID: <5-HktPHZPp7wH-7WdGkE6DnPqqAeG7It7Qp2e571aus=.b858f1b8-37a3-44be-a75e-3fb722d05573@github.com>

On Wed, 18 May 2022 14:21:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I'm not sure if there is anything actionable here?
>> 
>> I've thought in the past that it might be nice to have `GetArgument`/`SetArgument` and `GetReturnValue`/`SetReturnValue` binding operators as well, to make the inputs/outputs more explicit in the recipe. But, it doesn't seem like that would make things _much_ better...
>
> I wasn't suggesting to add more bindings. I was more suggesting to filter out the load/store from the set of bindings (since these are virtualized anyways) that are passed to `doBindings`. Then, before executing a set of bindings, (if we are in downcall mode) we load the corresponding input local var. After executing bindings (if we are in upcall mode) we store result in corresponding var.
> 
> E.g. make the logic that load locals and store locals explicit in the `specialize` method, rather than have parts of it execute "in  disguise" as "binding interpretation".

It's not quite that simple since a binding recipe for a single parameter can have multiple VMStores for instance if a struct is decomposed into multiple values.

It can be done by pulling the binding loops up to the `specialize` method, and have if statements for VMStore and VMLoad, like this:

    for (Binding binding : callingSequence.argumentBindings(i)) {
        if (binding instanceof Binding.VMStore vms && callingSequence.forDowncall()) {
            emitSetOutput(vms.type());
        } else if (binding instanceof Binding.VMLoad && callingSequence.forUpcall()) {
            emitGetInput();
        } else {
            doBinding(binding);
        }
    }

And for returns:

    for (Binding binding : callingSequence.returnBindings()) {
        if (binding instanceof Binding.VMLoad vml && callingSequence.forDowncall()) {
            if (!callingSequence.needsReturnBuffer()) {
                emitRestoreReturnValue(vml.type());
            } else {
                emitReturnBufferLoad(vml);
            }
        } else if (binding instanceof Binding.VMStore vms && callingSequence.forUpcall()) {
            if (!callingSequence.needsReturnBuffer()) {
                emitSaveReturnValue(vms.type());
            } else {
                emitReturnBufferStore(vms);
            }
        } else {
            doBinding(binding);
        }
    }

But, maybe that's better?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From duke at openjdk.java.net  Wed May 18 14:59:49 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 18 May 2022 14:59:49 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v2]
In-Reply-To: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
Message-ID: <HZ7Krri1nvZwxHK9gWR38oXbnSBntPl0OiOX8cVbB7w=.aa4a1456-f8e6-4045-afb4-1d1672d1f448@github.com>

> Hi,
> 
> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
> 
> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
> 
>     ucomiss xmm0, xmm0
>     jp      label
>     jne     label
> 
> into
> 
>     ucomiss xmm0, xmm0
>     jp      label
> 
> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
> 
>         xorl    ecx, ecx
>         ucomiss xmm0, xmm1
>         jnp     done
>         pushf
>         andq    [rsp], 0xffffff2b
>         popf
>     done:
>         movl    eax, 1
>         cmovel  eax, ecx
> 
> The patch changes this sequence into
> 
>     xorl    ecx, ecx
>     ucomiss xmm0, xmm1
>     movl    eax, 1
>     cmovpl  eax, ecx
>     cmovnel eax, ecx
> 
> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
> 
> The benchmark results are as follow:
> 
>     Before:
>     Benchmark                      Mode  Cnt     Score     Error  Units
>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  ns/op
>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  ns/op
>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  ns/op
>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  ns/op
>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  ns/op
>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  ns/op
>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  ns/op
>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  ns/op
> 
>     After:
>     Benchmark                      Mode  Cnt     Score     Error  Units
>     FPComparison.equalDouble       avgt    5   594.636 ?   8.922  ns/op
>     FPComparison.equalFloat        avgt    5   663.849 ?   3.656  ns/op
>     FPComparison.isFiniteDouble    avgt    5   518.309 ? 107.352  ns/op
>     FPComparison.isFiniteFloat     avgt    5   515.576 ?  14.669  ns/op
>     FPComparison.isInfiniteDouble  avgt    5   621.185 ?  11.935  ns/op
>     FPComparison.isInfiniteFloat   avgt    5   623.566 ?  15.206  ns/op
>     FPComparison.isNanDouble       avgt    5   400.124 ?   0.762  ns/op
>     FPComparison.isNanFloat        avgt    5   546.486 ?   1.509  ns/op
> 
> Thank you very much.

Quan Anh Mai 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 eight additional commits since the last revision:

 - incidental ws
 - add tests
 - Merge branch 'master' into fpcompare
 - fix tests
 - test
 - improve infinity
 - remove expensive rules
 - improve fp comparison

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8525/files
  - new: https://git.openjdk.java.net/jdk/pull/8525/files/b64e04b5..ba93dcf2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8525&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8525&range=00-01

  Stats: 210103 lines in 2627 files changed: 159508 ins; 36691 del; 13904 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8525.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8525/head:pull/8525

PR: https://git.openjdk.java.net/jdk/pull/8525

From lancea at openjdk.java.net  Wed May 18 14:59:56 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:59:56 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <H0aIQ5SRJgWgvc_Hp8Y6ClzE86lEOzNYOKiV56ueWU0=.9bf1a830-fb68-4f70-a254-3b5d182739ae@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8771

From duke at openjdk.java.net  Wed May 18 15:01:38 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 18 May 2022 15:01:38 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
In-Reply-To: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
Message-ID: <JWs3_k2RjekJyce9EByCxFvuJTQbpvu19A0ay4xB6P0=.1f9f7079-092f-43e4-9ee4-7e8b5fadb3c5@github.com>

On Wed, 4 May 2022 01:59:17 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
> 
> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
> 
>     ucomiss xmm0, xmm0
>     jp      label
>     jne     label
> 
> into
> 
>     ucomiss xmm0, xmm0
>     jp      label
> 
> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
> 
>         xorl    ecx, ecx
>         ucomiss xmm0, xmm1
>         jnp     done
>         pushf
>         andq    [rsp], 0xffffff2b
>         popf
>     done:
>         movl    eax, 1
>         cmovel  eax, ecx
> 
> The patch changes this sequence into
> 
>     xorl    ecx, ecx
>     ucomiss xmm0, xmm1
>     movl    eax, 1
>     cmovpl  eax, ecx
>     cmovnel eax, ecx
> 
> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
> 
> The benchmark results are as follow:
> 
>     Before:
>     Benchmark                      Mode  Cnt     Score     Error  Units
>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  ns/op
>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  ns/op
>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  ns/op
>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  ns/op
>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  ns/op
>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  ns/op
>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  ns/op
>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  ns/op
> 
>     After:
>     Benchmark                      Mode  Cnt     Score     Error  Units
>     FPComparison.equalDouble       avgt    5   594.636 ?   8.922  ns/op
>     FPComparison.equalFloat        avgt    5   663.849 ?   3.656  ns/op
>     FPComparison.isFiniteDouble    avgt    5   518.309 ? 107.352  ns/op
>     FPComparison.isFiniteFloat     avgt    5   515.576 ?  14.669  ns/op
>     FPComparison.isInfiniteDouble  avgt    5   621.185 ?  11.935  ns/op
>     FPComparison.isInfiniteFloat   avgt    5   623.566 ?  15.206  ns/op
>     FPComparison.isNanDouble       avgt    5   400.124 ?   0.762  ns/op
>     FPComparison.isNanFloat        avgt    5   546.486 ?   1.509  ns/op
> 
> Thank you very much.

I have reverted the changes to `java.lang.Float` and `java.lang.Double` to not interfere with the intrinsic PR. More tests are added to cover all cases regarding floating-point comparison of compiled code.

The rules for fp comparison that output the result to `rFlagRegsU` are expensive and should be avoided. As a result, I removed the shortcut rules with memory or constant operands to reduce the number of match rules. Only the basic rules are kept.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From dmarkov at openjdk.java.net  Wed May 18 15:07:48 2022
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Wed, 18 May 2022 15:07:48 GMT
Subject: RFR: 8284213: Replace usages of 'a the' in xml
In-Reply-To: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
References: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
Message-ID: <E_XMGURdFqgy9T0iTOIN4xSp_Giq4EgDzXZg2CCC0CY=.376cd331-4b22-4e07-9c26-075f9ad4b8e4@github.com>

On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I tried to avoid changing external libraries, there are quite a few such typos.
> Let me know if I should revert any files.

Marked as reviewed by dmarkov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8769

From jvernee at openjdk.java.net  Wed May 18 15:09:08 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 15:09:08 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <5-HktPHZPp7wH-7WdGkE6DnPqqAeG7It7Qp2e571aus=.b858f1b8-37a3-44be-a75e-3fb722d05573@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com>
 <WSWzMwK-S9uqtbR2DMc5adtSYpTmmkJhqYo5WsGZmKM=.17c0bb8e-a6a8-40ef-a1cb-c307eb62dd99@github.com>
 <ITgfGXeM7N9eezcUy6oOZJLOpg4iT0XoRC_MuS213kA=.e40677a8-a49f-477f-981e-83253c826e5c@github.com>
 <5-HktPHZPp7wH-7WdGkE6DnPqqAeG7It7Qp2e571aus=.b858f1b8-37a3-44be-a75e-3fb722d05573@github.com>
Message-ID: <E759beAAKolq1xYkptWY5zDb6EyYZIkcHPEpGCbKPAA=.0e480d9c-3b28-4279-8a50-fe5530bc125a@github.com>

On Wed, 18 May 2022 14:51:02 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I wasn't suggesting to add more bindings. I was more suggesting to filter out the load/store from the set of bindings (since these are virtualized anyways) that are passed to `doBindings`. Then, before executing a set of bindings, (if we are in downcall mode) we load the corresponding input local var. After executing bindings (if we are in upcall mode) we store result in corresponding var.
>> 
>> E.g. make the logic that load locals and store locals explicit in the `specialize` method, rather than have parts of it execute "in  disguise" as "binding interpretation".
>
> It's not quite that simple since a binding recipe for a single parameter can have multiple VMStores for instance if a struct is decomposed into multiple values.
> 
> It can be done by pulling the binding loops up to the `specialize` method, and have if statements for VMStore and VMLoad, like this:
> 
>     for (Binding binding : callingSequence.argumentBindings(i)) {
>         if (binding instanceof Binding.VMStore vms && callingSequence.forDowncall()) {
>             emitSetOutput(vms.type());
>         } else if (binding instanceof Binding.VMLoad && callingSequence.forUpcall()) {
>             emitGetInput();
>         } else {
>             doBinding(binding);
>         }
>     }
> 
> And for returns:
> 
>     for (Binding binding : callingSequence.returnBindings()) {
>         if (binding instanceof Binding.VMLoad vml && callingSequence.forDowncall()) {
>             if (!callingSequence.needsReturnBuffer()) {
>                 emitRestoreReturnValue(vml.type());
>             } else {
>                 emitReturnBufferLoad(vml);
>             }
>         } else if (binding instanceof Binding.VMStore vms && callingSequence.forUpcall()) {
>             if (!callingSequence.needsReturnBuffer()) {
>                 emitSaveReturnValue(vms.type());
>             } else {
>                 emitReturnBufferStore(vms);
>             }
>         } else {
>             doBinding(binding);
>         }
>     }
> 
> But, maybe that's better?

I think someone might look at this and think "why aren't these bindings handled by `doBinding`"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From wetmore at openjdk.java.net  Wed May 18 15:15:56 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 18 May 2022 15:15:56 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <AIjhEfuQaJLjZPeDl94HgUet9eMCoEwolZpNvKGGHGs=.bb1c32b4-65d8-40f2-84c3-38dc7db54894@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Looked at 

- java.base/.../sun/security
- jdk.crypto.*
- test/*/com/sun/crypto/provider
- test/*/java/lang/SecurityManager
- test/*/java/security
- test/*/krb5
- test/*/jarsigner

and those look fine.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From wetmore at openjdk.java.net  Wed May 18 15:19:55 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 18 May 2022 15:19:55 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <BlEMdHGx8wwWoDnuSLakASovW6f-yse6TPC3pbF6bcE=.8caab0de-e0bf-457d-883e-ae779ccff635@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Looked at 

-java.security.jgss.

LGTM

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From mcimadamore at openjdk.java.net  Wed May 18 15:36:55 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 18 May 2022 15:36:55 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v5]
In-Reply-To: <tjMWFm4IrX2RAoLSIArEKN5JqG-q1EM9Jyswq8JR6LU=.30a94102-4041-4b18-8cfa-235d0e68d2f1@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <tjMWFm4IrX2RAoLSIArEKN5JqG-q1EM9Jyswq8JR6LU=.30a94102-4041-4b18-8cfa-235d0e68d2f1@github.com>
Message-ID: <VJNf7MsHY_xpJPfcKuFcGnlZp0356n5npP4CcHoD-0I=.c2d91416-e624-4760-8872-5393c435348f@github.com>

On Wed, 18 May 2022 11:27:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
>> 
>> Thanks,
>> Jorn
>> 
>> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 118 commits:
> 
>  - Merge branch 'JEP-19-ASM' of https://github.com/JornVernee/jdk into JEP-19-ASM
>  - Merge branch 'pr/7959' into JEP-19-ASM
>  - Merge branch 'master' into JEP-19-VM-IMPL2
>  - ifdef NOT_PRODUCT -> ifndef PRODUCT
>  - Missing ASSERT -> NOT_PRODUCT
>  - Cleanup UL usage
>  - Fix failure with SPEC disabled (accidentally dropped change)
>  - indentation
>  - fix space
>  - Merge branch 'master' into JEP-19-ASM
>  - ... and 108 more: https://git.openjdk.java.net/jdk/compare/81e4bdbe...ce5c677a

Looks good!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8685

From mcimadamore at openjdk.java.net  Wed May 18 15:36:57 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 18 May 2022 15:36:57 GMT
Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in
 mainline [v3]
In-Reply-To: <E759beAAKolq1xYkptWY5zDb6EyYZIkcHPEpGCbKPAA=.0e480d9c-3b28-4279-8a50-fe5530bc125a@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
 <DcfsFx6KL_I-wQNhCXo1sdcAdg7Ir6Rk2H9kPu0xP1s=.ded71d7d-dd9c-4477-a410-d62c1940e840@github.com>
 <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com>
 <WSWzMwK-S9uqtbR2DMc5adtSYpTmmkJhqYo5WsGZmKM=.17c0bb8e-a6a8-40ef-a1cb-c307eb62dd99@github.com>
 <ITgfGXeM7N9eezcUy6oOZJLOpg4iT0XoRC_MuS213kA=.e40677a8-a49f-477f-981e-83253c826e5c@github.com>
 <5-HktPHZPp7wH-7WdGkE6DnPqqAeG7It7Qp2e571aus=.b858f1b8-37a3-44be-a75e-3fb722d05573@github.com>
 <E759beAAKolq1xYkptWY5zDb6EyYZIkcHPEpGCbKPAA=.0e480d9c-3b28-4279-8a50-fe5530bc125a@github.com>
Message-ID: <i18vT_asmG0khrPQDHmVLLlhCe7qQxaqaVdT_qPPKZ0=.3f1af1ec-35bc-4f11-83bd-f8ad6c993829@github.com>

On Wed, 18 May 2022 15:05:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> It's not quite that simple since a binding recipe for a single parameter can have multiple VMStores for instance if a struct is decomposed into multiple values.
>> 
>> It can be done by pulling the binding loops up to the `specialize` method, and have if statements for VMStore and VMLoad, like this:
>> 
>>     for (Binding binding : callingSequence.argumentBindings(i)) {
>>         if (binding instanceof Binding.VMStore vms && callingSequence.forDowncall()) {
>>             emitSetOutput(vms.type());
>>         } else if (binding instanceof Binding.VMLoad && callingSequence.forUpcall()) {
>>             emitGetInput();
>>         } else {
>>             doBinding(binding);
>>         }
>>     }
>> 
>> And for returns:
>> 
>>     for (Binding binding : callingSequence.returnBindings()) {
>>         if (binding instanceof Binding.VMLoad vml && callingSequence.forDowncall()) {
>>             if (!callingSequence.needsReturnBuffer()) {
>>                 emitRestoreReturnValue(vml.type());
>>             } else {
>>                 emitReturnBufferLoad(vml);
>>             }
>>         } else if (binding instanceof Binding.VMStore vms && callingSequence.forUpcall()) {
>>             if (!callingSequence.needsReturnBuffer()) {
>>                 emitSaveReturnValue(vms.type());
>>             } else {
>>                 emitReturnBufferStore(vms);
>>             }
>>         } else {
>>             doBinding(binding);
>>         }
>>     }
>> 
>> But, maybe that's better?
>
> I think someone might look at this and think "why aren't these bindings handled by `doBinding`"?

Let's leave it as is for the time being. I guess what I'm trying to get at is to try and make the code more explicit - but that is hard, given the constraints.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From duke at openjdk.java.net  Wed May 18 15:51:22 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 18 May 2022 15:51:22 GMT
Subject: RFR: 8286182: C2: crash with SIGFPE when executing compiled code
Message-ID: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>

This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above its validity checks.

Thanks.

-------------

Commit messages:
 - Revert "8284742: x86: Handle integral division overflow during parsing"
 - Revert "8285390: PPC64: Handle integral division overflow during parsing"

Changes: https://git.openjdk.java.net/jdk/pull/8774/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8774&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286182
  Stats: 967 lines in 25 files changed: 364 ins; 476 del; 127 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8774.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8774/head:pull/8774

PR: https://git.openjdk.java.net/jdk/pull/8774

From duke at openjdk.java.net  Wed May 18 15:55:58 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 18 May 2022 15:55:58 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v2]
In-Reply-To: <6hRgLEWJfB8OHOYNJReUaMac469hvDuemoURK-aMy4Y=.963b7561-33e0-4069-8d89-8b447d4e0f0f@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <KdpuTVQMeytKodsxscUf6bY-Rb9ZX1mh-JlqxGz3yhc=.ad30bd97-86fe-4ae8-80ff-277eacce88d9@github.com>
 <6hRgLEWJfB8OHOYNJReUaMac469hvDuemoURK-aMy4Y=.963b7561-33e0-4069-8d89-8b447d4e0f0f@github.com>
Message-ID: <9U6TeG5OxWKYDHqd4X4SvId4jPXNeG0F0KxubPYdrYQ=.1b09aef1-5de6-47b4-b674-02f521ef9825@github.com>

On Wed, 4 May 2022 23:16:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_64.ad line 6998:
>> 
>>> 6996:   ins_encode %{
>>> 6997:     __ cmovl(Assembler::parity, $dst$$Register, $src$$Register);
>>> 6998:     __ cmovl(Assembler::notEqual, $dst$$Register, $src$$Register);
>> 
>> Should this be `equal`?
>
> I see that you swapped `src, dst` in `match()` but `format` is sill incorrect and the code is confusing.

This is a flipping the sense of the test by flipping the input of the `CMove`, so this is essentially the same as in the above rule. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From jvernee at openjdk.java.net  Wed May 18 16:06:01 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 16:06:01 GMT
Subject: Integrated: 8286669: Replace MethodHandle specialization with ASM in
 mainline
In-Reply-To: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
References: <lzAWqlcE6av-0iP62pU7chYwA1WDFlcDIssiESXVbCw=.d13f3473-49dd-4b1e-9ed2-9f4a57eac830@github.com>
Message-ID: <mIANe0pEAHZKNA5Z_VcL5KBPahXgQEaqXxWqYqnqPmg=.a629afc0-5763-41c4-9014-3ddf95cc90e4@github.com>

On Thu, 12 May 2022 17:17:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well.
> 
> Thanks,
> Jorn
> 
> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux.

This pull request has now been integrated.

Changeset: ee45a0ac
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ee45a0ac63613312b4f17dcd55e8defa94c34669
Stats:     2142 lines in 24 files changed: 1357 ins; 660 del; 125 mod

8286669: Replace MethodHandle specialization with ASM in mainline

Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.java.net/jdk/pull/8685

From dfuchs at openjdk.java.net  Wed May 18 16:07:52 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 18 May 2022 16:07:52 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <hqiM9eFHWbK89Zfb-ZaJGalvghiDsyvw09l6hQI8YxA=.6cb984f1-c988-4f52-bd07-406a5362fe70@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Logging/JNDI OK

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From naoto at openjdk.java.net  Wed May 18 16:18:58 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 18 May 2022 16:18:58 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <4eXpe5pmBsvw8u6fJlzd9BWsnY74LiyjTqQhQ88uxoc=.6182985a-f751-4d55-b9d0-bc605d7636da@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

LGTM for i18n changes.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From mdoerr at openjdk.java.net  Wed May 18 16:21:44 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 18 May 2022 16:21:44 GMT
Subject: RFR: 8286182: C2: crash with SIGFPE when executing compiled code
In-Reply-To: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
References: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
Message-ID: <67WWMvwBqtJvlgMWW7KaYrropJ0uvwHUwW0WbcTWmJ0=.5798663a-31fc-4945-8243-17e989e1c2fd@github.com>

On Wed, 18 May 2022 15:44:10 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above its validity checks.
> 
> Thanks.

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8774

From ssahoo at openjdk.java.net  Wed May 18 16:27:13 2022
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Wed, 18 May 2022 16:27:13 GMT
Subject: RFR: 8286969: Add a new test library API to execute kinit in
 SecurityTools.java
Message-ID: <uOfMWhhfyxQQ6Eyu_lvb_NAmaG8GbpX-zi2MmTWnzfE=.c54696d5-f224-44f7-b878-88767f53c530@github.com>

A new API to execute kinit.

-------------

Commit messages:
 - 8286969: Add a new test library API to execute kinit in SecurityTools.java

Changes: https://git.openjdk.java.net/jdk/pull/8775/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8775&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286969
  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8775.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8775/head:pull/8775

PR: https://git.openjdk.java.net/jdk/pull/8775

From naoto at openjdk.java.net  Wed May 18 16:35:28 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 18 May 2022 16:35:28 GMT
Subject: RFR: 8267038: Update IANA Language Subtag Registry to Version
 2022-03-02
Message-ID: <CZtyBskEU020ETi-1KB0QPOyM1lQ5R0ea86nclLAac0=.626db933-7d76-4307-83a4-6217471bcb64@github.com>

This is to incorporate the latest language subtag registry definition (version 2022-03-02) into JDK19.

-------------

Commit messages:
 - LSR 2022-03-02
 - LSR 2021-12-29
 - LSR 2021-08-06
 - LSR 2021-07-21

Changes: https://git.openjdk.java.net/jdk/pull/8776/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8776&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267038
  Stats: 281 lines in 2 files changed: 271 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8776.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8776/head:pull/8776

PR: https://git.openjdk.java.net/jdk/pull/8776

From iris at openjdk.java.net  Wed May 18 16:44:49 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 16:44:49 GMT
Subject: RFR: 8284213: Replace usages of 'a the' in xml
In-Reply-To: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
References: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
Message-ID: <7fkS7t7YAVxAGVO7abeDDMweepFcoOD-DiooZpdLpQ0=.f70a04e9-9206-426d-a81f-2cc1510ec790@github.com>

On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I tried to avoid changing external libraries, there are quite a few such typos.
> Let me know if I should revert any files.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8769

From prr at openjdk.java.net  Wed May 18 16:49:40 2022
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 18 May 2022 16:49:40 GMT
Subject: RFR: 8284213: Replace usages of 'a the' in xml
In-Reply-To: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
References: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
Message-ID: <7k0T22HtUdVnlTISxOlZ0gNxLdS6HZTgmkbwpAd4o7c=.e23eb78f-982d-43e6-a7a2-165834a34474@github.com>

On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I tried to avoid changing external libraries, there are quite a few such typos.
> Let me know if I should revert any files.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8769

From joehw at openjdk.java.net  Wed May 18 16:59:49 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 18 May 2022 16:59:49 GMT
Subject: RFR: 8284213: Replace usages of 'a the' in xml
In-Reply-To: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
References: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
Message-ID: <JBd3kNLsjzIDUhrCFdZwpXhL-JsWmyfoyqwzj6PTLYE=.3f0118d6-1b7b-46ec-ac8f-a6fe528c969f@github.com>

On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I tried to avoid changing external libraries, there are quite a few such typos.
> Let me know if I should revert any files.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8769

From iris at openjdk.java.net  Wed May 18 16:59:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 16:59:50 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <pRvaphDcC8dB1bZPh6x4OhyZ8BHSfCn9ZCdBzq9Dnco=.1ca1edd4-0004-43b9-815c-3b20ffb5368f@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From iris at openjdk.java.net  Wed May 18 17:04:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 17:04:50 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <KFAmufl8fur2ZWbG3C6rN_8h7oficN_4ViuHJ7hfvg4=.3ee598c2-3fd1-4344-bd94-89459431f74b@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8771

From jvernee at openjdk.java.net  Wed May 18 17:24:44 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 May 2022 17:24:44 GMT
Subject: RFR: 8286825: Linker naming cleanup
Message-ID: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>

This patch is a batch naming cleanup for the foreign linker implementation.

The naming changes are as follows:

  - ProgrammableInvoker -> DowncallLinker
  - ProgrammableUpcallHandler -> UpcallLinker
  - 'native invoker' -> 'downcall stub'
  - 'optimzed entry blob' -> 'upcall stub'
  - OptimizedEntryBlob -> UpcallStub
  - optimized_entry_frame -> upcall_stub_frame

Then renaming of some hotspot files:

  - universalNativeInvoker* -> downcallLinker*
  - universalUpcallHandler* -> upcallLinker*
  - foreign_globals* -> foreignGlobals* (to match existing convention)
  
Method, field, and other variable names are also adjusted accordingly.

-------------

Commit messages:
 - 8275648: Linker naming bikeshed

Changes: https://git.openjdk.java.net/jdk/pull/8777/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8777&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286825
  Stats: 2397 lines in 84 files changed: 1086 ins; 1090 del; 221 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8777.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8777/head:pull/8777

PR: https://git.openjdk.java.net/jdk/pull/8777

From sgehwolf at openjdk.java.net  Wed May 18 18:14:52 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 May 2022 18:14:52 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
Message-ID: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>

> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
> 
> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
> 
> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
> 
> Testing:
> - [x] Added unit tests
> - [x] GHA
> - [x] Container tests on cgroups v1 Linux. Continue to pass

Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor hotspot gtest
 - Separate into function. Fix comment.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8629/files
  - new: https://git.openjdk.java.net/jdk/pull/8629/files/66241aa5..4b8e92fa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8629&range=01-02

  Stats: 93 lines in 3 files changed: 56 ins; 25 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8629.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8629/head:pull/8629

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Wed May 18 18:14:55 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 May 2022 18:14:55 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
Message-ID: <MJKt4LfScjBzsqrbVdVpeBRqai7vP1uq0pvZqnYVp7Q=.1882c0a0-770e-4048-8a29-a1fb98c14bf4@github.com>

On Tue, 17 May 2022 06:18:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use stringStream to simplify controller path assembly
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:
> 
>> 90:           }
>> 91:           ss.print_raw(_root, last_matching_slash_pos);
>> 92:           _path = os::strdup(ss.base());
> 
> Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand.

@iklam yes I meant `Find the longest common prefix`. Fixed the comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From sgehwolf at openjdk.java.net  Wed May 18 18:14:57 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 18 May 2022 18:14:57 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <MJKt4LfScjBzsqrbVdVpeBRqai7vP1uq0pvZqnYVp7Q=.1882c0a0-770e-4048-8a29-a1fb98c14bf4@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
 <MJKt4LfScjBzsqrbVdVpeBRqai7vP1uq0pvZqnYVp7Q=.1882c0a0-770e-4048-8a29-a1fb98c14bf4@github.com>
Message-ID: <MufMBz_4YPBASS5M7ZqphZBcRSJL1VrNQnsqEAIn30Y=.c5e1a8ce-8e78-4526-8283-9b4ef82c6dfa@github.com>

On Wed, 18 May 2022 18:09:54 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 92:
>> 
>>> 90:           }
>>> 91:           ss.print_raw(_root, last_matching_slash_pos);
>>> 92:           _path = os::strdup(ss.base());
>> 
>> Do you mean `Find the longest common prefix`? Maybe give an example in the comments? Text parsing in C code is really difficult to understand.
>
> @iklam yes I meant `Find the longest common prefix`. Fixed the comment.

I'm not convinced the extra function makes the code more readable, but here it is. I can revert back if this is too much.

>> test/hotspot/gtest/runtime/test_os_linux_cgroups.cpp line 63:
>> 
>>> 61:     ASSERT_STREQ(expected_cg_paths[i], ctrl->subsystem_path());
>>> 62:   }
>>> 63: }
>> 
>> I found it hard to relate the different paths. Could you create a new struct like this?
>> 
>> 
>> struct TestCase {
>>     char* mount_path;
>>     char* root_paths;
>>     char* cgroup_path;
>>     char* expected_cg_paths;
>> } = {
>>   {  "/sys/fs/cgroup/memory",     // mount
>>        "/",                       // root,
>>        ....
>
> Yes, makes sense. Will do.

Done now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From duke at openjdk.java.net  Wed May 18 18:16:55 2022
From: duke at openjdk.java.net (Shruthi)
Date: Wed, 18 May 2022 18:16:55 GMT
Subject: Integrated: 8285097: Duplicate XML keys in XPATHErrorResources.java
 and XSLTErrorResources.java
In-Reply-To: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
References: <wtWo5YVgwzt6jtox9ldmBjfhtR0d8Bb0tlKK1xWEe9U=.e648b720-d114-4065-a35b-1884b9c8f1ed@github.com>
Message-ID: <Kt5rh7lI_kGkVg5z9o89Jwo3ruK72dmYKas1g4-fb4M=.7b3acf47-c082-4c3e-b90c-c64cb6c4786f@github.com>

On Wed, 20 Apr 2022 15:37:13 GMT, Shruthi <duke at openjdk.java.net> wrote:

> Removing the Duplicate keys present in XSLTErrorResources.java and XPATHErrorResources.java
> 
> The bug report for the same: https://bugs.openjdk.java.net/browse/JDK-8285097

This pull request has now been integrated.

Changeset: b5a3d284
Author:    Shruthi <Shruthi.Shruthi1 at ibm.com>
Committer: Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b5a3d2843be3c093cd3a534caece87a32e5c47cc
Stats:     50 lines in 13 files changed: 8 ins; 13 del; 29 mod

8285097: Duplicate XML keys in XPATHErrorResources.java and XSLTErrorResources.java

Reviewed-by: joehw, tsteele

-------------

PR: https://git.openjdk.java.net/jdk/pull/8318

From almatvee at openjdk.java.net  Wed May 18 20:25:43 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 18 May 2022 20:25:43 GMT
Subject: Integrated: 8286122: [macos]: App bundle cannot upload to Mac App
 Store due to info.plist embedded in java exe
In-Reply-To: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
Message-ID: <tZQLCOSpqO6_mRqZvUkAAbnDkVUQMpoECs9AFgu1XKg=.ced20990-1c5f-404f-b1e5-5c10851312f1@github.com>

On Wed, 11 May 2022 21:31:44 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.
>  - With proposed fix we will enforce "--strip-native-commands" option for jlink, so native JDK commands are not included when generating Mac App Store bundles.
>  - Custom runtime provided via --runtime-image should not contain native commands as well, otherwise jpackage will throw error.
>  - Added two tests to validate fix.

This pull request has now been integrated.

Changeset: b523c884
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b523c88480ba5c8f9d78537c9de0abcbf1f867c0
Stats:     221 lines in 7 files changed: 216 ins; 1 del; 4 mod

8286122: [macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe

Reviewed-by: asemenyuk, kcr

-------------

PR: https://git.openjdk.java.net/jdk/pull/8666

From duke at openjdk.java.net  Wed May 18 21:51:01 2022
From: duke at openjdk.java.net (zhw970623)
Date: Wed, 18 May 2022 21:51:01 GMT
Subject: RFR: 8286462: Incorrect copyright year for
 src/java.base/share/classes/jdk/internal/vm/FillerObject.java
Message-ID: <89Lf5xlbDoqPUpi9dK24kvS3fP8DvZkw0cbKeCNDdbI=.935b15e6-8942-47d6-9b84-8319bcde2a86@github.com>

The copyright year of src/java.base/share/classes/jdk/internal/vm/FillerObject.java should be 2022.

-------------

Commit messages:
 - [PATCH] 8286462: The copyright year of src/java.base/share/classes/jdk/internal/vm/FillerObject.java should be 2022

Changes: https://git.openjdk.java.net/jdk/pull/8633/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8633&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286462
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8633/head:pull/8633

PR: https://git.openjdk.java.net/jdk/pull/8633

From jjg at openjdk.java.net  Wed May 18 22:06:44 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 18 May 2022 22:06:44 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <aEkG0OZ86yGP3oWxO4p1nrLGfm0uEdI0SOvg4EczMaY=.c368691e-af13-46dc-8e60-b664f8094e00@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

javac and javadoc changes look OK

test/langtools/tools/javac/modules/T8168854/module-info.java line 4:

> 2:  * @test
> 3:  * @bug 8168854
> 4:  * @summary javac erroneously reject a service interface inner class in a provides clause

FYI, this duplication was in the JBS issue summary; now fixed there.

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From bpb at openjdk.java.net  Wed May 18 23:02:20 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 18 May 2022 23:02:20 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v4]
In-Reply-To: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
Message-ID: <VNtuvnrEmP9MkAoEpV2P3xpEwatwZ6nwfd72HJwXGyk=.618c6e7a-12f8-4163-adc5-e11a11513f03@github.com>

> Modify native multi-byte read-write code used by the `java.io` classes to limit the size of the allocated native buffer thereby decreasing off-heap memory footprint and increasing throughput.

Brian Burkhalter 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 six additional commits since the last revision:

 - 6478546: Add break in write loop on ExceptionOccurred
 - Merge
 - 6478546: Clean up io_util.c
 - Merge
 - 6478546: Decrease malloc'ed buffer maximum size to 64 kB
 - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8235/files
  - new: https://git.openjdk.java.net/jdk/pull/8235/files/5c3a3446..10f14bb3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8235&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8235&range=02-03

  Stats: 232900 lines in 3152 files changed: 173230 ins; 42904 del; 16766 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8235.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8235/head:pull/8235

PR: https://git.openjdk.java.net/jdk/pull/8235

From bpb at openjdk.java.net  Wed May 18 23:02:26 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 18 May 2022 23:02:26 GMT
Subject: RFR: 6478546: FileInputStream.read() throws OutOfMemoryError when
 there is plenty available [v3]
In-Reply-To: <_D7JUQjjeAtDWiSqQOTt5rA-EyHcb8ChA5JKnaIYoQw=.cf6b8e50-ece7-46fd-8327-b9b8f7dddf56@github.com>
References: <7zMVWPqTuT6RazzzaPgj41iN6BjrlpYS2a2NFoFO_-k=.67ac646d-f4bb-4d4f-8f96-f90fd03908a1@github.com>
 <3eDsmvMyBrMn89BpVmMcG6Xyb3m5vM8DzKV-vDhxFXY=.a1553712-81f4-4434-9522-e7dbd7fbbb60@github.com>
 <_D7JUQjjeAtDWiSqQOTt5rA-EyHcb8ChA5JKnaIYoQw=.cf6b8e50-ece7-46fd-8327-b9b8f7dddf56@github.com>
Message-ID: <b0H2_pZyIuXUMT5OGtbDQkTR1L26DJLyxz-LUjXLUa8=.a28dbaa0-8fb0-4606-a3fc-1be0e4efcc28@github.com>

On Thu, 12 May 2022 07:59:36 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Brian Burkhalter 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:
>> 
>>  - 6478546: Clean up io_util.c
>>  - Merge
>>  - 6478546: Decrease malloc'ed buffer maximum size to 64 kB
>>  - 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available
>
> src/java.base/share/native/libjava/io_util.c line 79:
> 
>> 77:           jint off, jint len, jfieldID fid)
>> 78: {
>> 79:     char stackBuf[STACK_BUF_SIZE];
> 
> This was in the original code already, but doesn't this always allocate 8k on the stack, regardless of whether this buffer will be used (if len > 8k or len == 0)?  Wouldn't it be better to allocate this only in the `else` case?
> 
> Would apply to the write code as well.

This is intentional. We want to avoid having a malloc + free in every call and so avoid it for small buffers.

> src/java.base/share/native/libjava/io_util.c line 81:
> 
>> 79:     char stackBuf[STACK_BUF_SIZE];
>> 80:     char *buf = NULL;
>> 81:     jint buf_size, read_size;;
> 
> minor: double semi colon

FIxed in 10f14bb3faef2b55ab59a85016874d12815f3c87.

> src/java.base/share/native/libjava/io_util.c line 129:
> 
>> 127:             off += n;
>> 128:         } else if (n == -1) {
>> 129:             JNU_ThrowIOExceptionWithLastError(env, "Read error");
> 
> The original code would have `nread` set to `-1` here, and thus exit with `-1`.  The new code would exit with the last value for `nread` which could be anything.

The returned value of `nread` would in this case indicate the number of bytes actually read so far, which is intentional.

> src/java.base/share/native/libjava/io_util.c line 201:
> 
>> 199:         write_size = len < buf_size ? len : buf_size;
>> 200:         (*env)->GetByteArrayRegion(env, bytes, off, write_size, (jbyte*)buf);
>> 201:         if (!(*env)->ExceptionOccurred(env)) {
> 
> Wouldn't this result in an infinite loop if `GetByteArrayRegion` triggered an exception and `len > 0` ?  It would never enter the `if` and `len` is never changed then...

Good catch, you are correct. Fixed in 10f14bb3faef2b55ab59a85016874d12815f3c87.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8235

From smarks at openjdk.java.net  Wed May 18 23:23:56 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 18 May 2022 23:23:56 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v4]
In-Reply-To: <9PqOY0Ho6mgINFO8ya5NeaZZB3RaATgWx7LJ-ESRSds=.37fdca9a-7af5-4ba5-8c85-baf9d33013ac@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <dG50e4tph85P83R-ErBDznD1MCRHJ981upFennWzxTc=.afb7c439-9284-4396-94b1-8a9c6aac5d2e@github.com>
 <4I-FrEU8zBFD0-4pDPYZ948aQvIXHicUyTpbiUqKTj8=.377d95a6-af67-44be-8443-c4af58f8b95e@github.com>
 <9PqOY0Ho6mgINFO8ya5NeaZZB3RaATgWx7LJ-ESRSds=.37fdca9a-7af5-4ba5-8c85-baf9d33013ac@github.com>
Message-ID: <xMAQ0rG1GEFkU-ct6ub6Ezln8hoHnn2jHkmGWZ3J3bQ=.16aecdda-aa21-48a0-9f91-044a604651dd@github.com>

On Wed, 20 Apr 2022 16:14:42 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> Need to add apiNote documentation section to capacity-based constructors like for maps.
>
>> Need to add apiNote documentation section to capacity-based constructors like for maps.
> 
> @liach done.

@XenoAmess oops, sorry for the delay. I think it would be good to get these into 19 as companions to `HashMap.newHashMap` et. al.

As before, I'd suggest reducing the number of changes to use sites in order to make review easier. I would suggest keeping the changes under src in java.base, java.net.http, java.rmi, and jdk.zipfs, and omitting all the other changes. Also keep the changes under test/jdk.

There needs to be a test for these new methods. I haven't thought much how to do that. My first attempt would be to modify our favorite WhiteBoxResizeTest and add a bit of machinery that asserts the table length of the HashMap contained within the created HashSet/LinkedHashSet. I haven't looked at it though, so it might not work out, in which case you should pursue an alternative approach.

I'll look at the specs and suggest updates as necessary and then handle filing of a CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From vlivanov at openjdk.java.net  Wed May 18 23:25:42 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 18 May 2022 23:25:42 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v6]
In-Reply-To: <dKj9d0RwFCkNlTZZ7nFEBu4zl_Wjj5RwRmH7-4q4QXU=.c6086bbc-055c-41e1-ae50-47797aa74b70@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
 <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
 <dKj9d0RwFCkNlTZZ7nFEBu4zl_Wjj5RwRmH7-4q4QXU=.c6086bbc-055c-41e1-ae50-47797aa74b70@github.com>
Message-ID: <-lS_36hGarJvCL26lgWyXJd-e2SuLD9g1wWL5PuoLXI=.5ddb3b74-493f-41df-8544-8a963c66fc5d@github.com>

On Fri, 13 May 2022 08:24:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> LUT should be generated only if UsePopCountInsturction is false 

Should there be `!UsePopCountInsturction` check then?

> restrict the scope of flag to only scalar popcount operation

Interesting. But AArch64 code does cover vector cases which just adds confusion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From vlivanov at openjdk.java.net  Wed May 18 23:39:53 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 18 May 2022 23:39:53 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v3]
In-Reply-To: <Sbf6Rj5Zz8KFJIGpJmdMH9ScVs3CeKgINDk4d8L-nNc=.e259a479-e03f-445a-a641-413fe0183ec8@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
 <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
 <Sbf6Rj5Zz8KFJIGpJmdMH9ScVs3CeKgINDk4d8L-nNc=.e259a479-e03f-445a-a641-413fe0183ec8@github.com>
Message-ID: <rWRoQRmRyI6tQ4SeZo1qC9Pbc201-YytIVrGX3wBJ9E=.e364352d-f6af-48f9-bf86-dc27fa977468@github.com>

On Fri, 13 May 2022 08:24:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/c2compiler.cpp line 521:
>> 
>>> 519:     if (!Matcher::match_rule_supported(Op_SignumF)) return false;
>>> 520:     break;
>>> 521:   case vmIntrinsics::_VectorComExp:
>> 
>> Why `_VectorComExp` intrinsic is special? Other vector intrinsics are handled later and in a different manner.
>> 
>> What about `ExpandV` case?
>
> It was an attempt to facilitate in-lining of these APIs over targets which do not intrinsify them. I agree its not a generic fix since three APIs are piggybacking on same entry point and without the knowledge of opcode it will be inappropriate to take any call at this place, lazy intrinsification gives opportunity for some of the predications to concertize as compilation happens under closed world assumptions.

Still not clear why the code is shaped the way it is.

`Matcher::match_rule_supported_vector()` already checks that there are relevant matching rules.

The checks require both `CompressM` and `CompressV` to be present to enable the intrinsic. Is it important?

Also, it doesn't take `EnableVectorSupport` into account while all other vector intrinsics respect it.

>> src/hotspot/share/opto/compile.cpp line 3416:
>> 
>>> 3414: 
>>> 3415:   case Op_ReverseBytesV:
>>> 3416:   case Op_ReverseV: {
>> 
>> Can you elaborate, please, why it is performed so late in the optimization phase (at the very end during graph reshaping) and not during GVN?
>
> Its more of a chicken-egg problem here, for masked reverse operation, Reverse IR node is followed by a Blend Node, thus in such a case doing an eager Identity transform in Reverse::Identity will not work, also deferring this to blend may also not work since it could be a non-masked reverse operation, we could have handled it as a special case in inline_vector_nary_operation, but handling such special case in final graph reshaping looked more appropriate.
> 
> https://github.com/openjdk/panama-vector/pull/182#discussion_r845678080

Do you mean it's important to apply the transformation at the right node (pick the right node as the root) and it is hard to make a decision during GVN?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From jiefu at openjdk.java.net  Thu May 19 00:40:35 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 19 May 2022 00:40:35 GMT
Subject: RFR: 8286462: Incorrect copyright year for
 src/java.base/share/classes/jdk/internal/vm/FillerObject.java
In-Reply-To: <89Lf5xlbDoqPUpi9dK24kvS3fP8DvZkw0cbKeCNDdbI=.935b15e6-8942-47d6-9b84-8319bcde2a86@github.com>
References: <89Lf5xlbDoqPUpi9dK24kvS3fP8DvZkw0cbKeCNDdbI=.935b15e6-8942-47d6-9b84-8319bcde2a86@github.com>
Message-ID: <s3l6EDsegCF9fD7WTzybi4rfKzz6C4-hBPZRgSA_kh8=.b90eb13b-6923-42ff-a8ae-e2240c611ad1@github.com>

On Tue, 10 May 2022 14:58:28 GMT, zhw970623 <duke at openjdk.java.net> wrote:

> The copyright year of src/java.base/share/classes/jdk/internal/vm/FillerObject.java should be 2022.

Looks good and trivial.
Thanks for spotting and fixing it.

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8633

From mik3hall at gmail.com  Thu May 19 01:44:46 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 18 May 2022 20:44:46 -0500
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
Message-ID: <100F2A28-281F-4F19-A07E-846B414FD517@gmail.com>



> On May 11, 2022, at 4:39 PM, Alexander Matveev <almatvee at openjdk.java.net> wrote:
> 
> - It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.

I was just thinking about this. If you wanted a workaround to suggest to the user on the original issue. You could jar the native executables, extract them to a known accessible location, and then runtime them.

Having the commands jar?d would get them past the App Store check. Runtime on the client machine I doubt would object to the duplicate bundle id?s on absolute path execution but I haven?t double checked that. Also avoids issues with quarantine xattr?s. 
I?ve done something like this a couple times for interfacing an app to other languages. 

For example?

			if (Files.exists(rscriptCmd)) {
				isR = true;
				System.out.println("InitialFinance: RScript available");
				// Where is the finance data directory?
				String data = prefs.get("data","N/A");
				
				if (data.equals("N/A")) {
					Application app = Application.getApplication();
					Path documents = app.getFolder(DataTypes.DOCUMENTS);
					dataLoc = Paths.get(documents.toString(),"finance");
				}
				else {
					dataLoc = Paths.get(data);					
				}
				System.out.println("InitialFinance: data location is " + dataLoc);
				Path resourceJar = Paths.get(System.getProperty("app.path"),"resource.jar");	
				System.out.println("InitialFinance: Checking resources for updates");
				extractArchive(resourceJar,dataLoc);
			}
			else {
				System.out.println("InitialFinance: " + rscriptCmd + " for " + initialRscript + " does not exist");
				isR = false;
			}

	// https://stackoverflow.com/questions/1529611/how-to-write-a-java-program-which-can-extract-a-jar-file-and-store-its-data-in-s
    public static void extractArchive(Path archiveFile, Path destPath) throws IOException {
        Files.createDirectories(destPath); // create dest path folder(s)
        try (ZipFile archive = new ZipFile(archiveFile.toFile())) {

        	@SuppressWarnings("unchecked")
        	Enumeration<ZipEntry> entries = (Enumeration<ZipEntry>) archive.entries();

            // copy or create new or updated
        	while (entries.hasMoreElements()) {
        		ZipEntry entry = entries.nextElement();
        		
        		if (!entry.getName().startsWith("finance/") || !(entry.getName().length() > 8)) {
        			continue;
        		}
        		String fileName = entry.getName().substring(8);
        		FileTime archiveTime = entry.getLastModifiedTime();

                Path entryDest = destPath.resolve(fileName);
                //if (Files.isDirectory(entryDest)) continue;
                //Files.createDirectories(entryDest);
        		if (!Files.exists(entryDest)) {
        			Files.copy(archive.getInputStream(entry), entryDest, StandardCopyOption.REPLACE_EXISTING);   
        			continue;
        		}
                BasicFileAttributes destAttr =
                        Files.readAttributes(entryDest, BasicFileAttributes.class);
                
                if (archiveTime.compareTo(destAttr.creationTime()) > 0) {
                    Files.copy(archive.getInputStream(entry), entryDest, StandardCopyOption.REPLACE_EXISTING);               	
                }
            }
        }
        catch (IOException ioex) {
        	throw ioex;
        }
    }

boolean debug = Boolean.getBoolean("R.debug");
				rtexec(new String[] { RSCRIPT, script.toString() },debug);
 

From ysuenaga at openjdk.java.net  Thu May 19 05:56:48 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 19 May 2022 05:56:48 GMT
Subject: Integrated: 8286694: Incorrect argument processing in java launcher
In-Reply-To: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
References: <r8DYi6OEZB3uyAQzdpSUXh0IUFOn_Ls4qkQUllorVWM=.7c8e8998-ad21-4779-bd48-0cadb3c2336c@github.com>
Message-ID: <tlsr-czgkAbIOpkry3VVxzKksxvKMueHYKFLymckCZk=.b1756069-e8dd-45c8-867d-87f177bfbb64@github.com>

On Fri, 13 May 2022 08:56:59 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> GCC 12 reports as following:

This pull request has now been integrated.

Changeset: 26c7c92b
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/26c7c92bc93f3eecf7ce69c69f1999ba879d1d60
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8286694: Incorrect argument processing in java launcher

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/8694

From thartmann at openjdk.java.net  Thu May 19 06:10:41 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 19 May 2022 06:10:41 GMT
Subject: RFR: 8286182: C2: crash with SIGFPE when executing compiled code
In-Reply-To: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
References: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
Message-ID: <4iJsDLmfjCyFoMXZnwR5H73_CCwokPNfZHLL82XIvtI=.b184d1b7-bdbf-4d7e-87d1-1b888c2675e8@github.com>

On Wed, 18 May 2022 15:44:10 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above their validity checks.
> 
> Thanks.

Looks good to me too but the backout should adhere to the process defined here: https://openjdk.java.net/guide/#backing-out-a-change

I would suggest "Alternative 2" of 3.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8774

From iklam at openjdk.java.net  Thu May 19 06:21:58 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 19 May 2022 06:21:58 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
Message-ID: <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>

On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter).
>> 
>> In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running.
>> 
>> Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round).
>> 
>> Testing:
>> - [x] Added unit tests
>> - [x] GHA
>> - [x] Container tests on cgroups v1 Linux. Continue to pass
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor hotspot gtest
>  - Separate into function. Fix comment.

Changes requested by iklam (Reviewer).

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 60:

> 58:         strncpy(buf, _mount_point, MAXPATHLEN);
> 59:         buf[MAXPATHLEN-1] = '\0';
> 60:         _path = os::strdup(buf);

Comment on the old code: why this cannot be simply


_path = os::strdup(_mount_point);


Also, all the strncat calls in this function seem problematic, and should be converted to stringStream for consistency.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 63:

> 61:       } else {
> 62:         char *p = strstr(cgroup_path, _root);
> 63:         if (p != NULL && p == cgroup_path) {

What happens if cgroup_path is "/foo/bar" and _root is "/fo"?

Maybe this block should be combined with the new `else` block you're adding? However, the behavior seems opposite between these two blocks of code:

The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path


  TestCase substring_match = {
    "/sys/fs/cgroup/memory",                           // mount_path
    "/user.slice/user-1000.slice",                     // root_path
    "/user.slice/user-1000.slice/user at 1001.service",   // cgroup_path
    "/sys/fs/cgroup/memory/user at 1001.service"          // expected_path
  };


The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path


 TestCase prefix_matched_cg = {
    "/sys/fs/cgroup/memory",                           // mount_path
    "/user.slice/user-1000.slice/session-50.scope",    // root_path
    "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
    "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path
  };


I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 86:

> 84:           const char* cgroup_p = cgroup_path;
> 85:           int last_slash = find_last_slash_pos(root_p, cgroup_p);
> 86:           assert(last_slash >= 0, "not an absolute path?");

Are root_p and cgroup_p directly read from the /proc/xxx files. If so, do we validate the input to make sure they are absolute paths?

It seems like our code cannot handle trailing '/' in the input. If so, we should clear all trailing '/' from the input string. Then, in functions that process them, we should assert that they don't end with slash. See my comment in find_last_slash_pos().

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 102:

> 100:   for (int i = 0; *s1 == *s2 && *s1 != 0; i++) {
> 101:     if (*s1 == '/') {
> 102:       last_matching_slash_pos = i;

I found the behavior a little hard to understand. Is it intentional?


"/cat/cow", "/cat/dog"    -> "/cat/"
"/cat/",    "/cat/dog"    -> "/cat/"
"/cat",     "/cat/dog"    -> "/"


The name `find_last_slash_pos` doesn't properly describe the behavior. I thought about `find_common_path_prefix`, but that doesn't match the current behavior (for the 3rd case, the common path prefix is `"/cat"`).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From chagedorn at openjdk.java.net  Thu May 19 06:58:53 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 19 May 2022 06:58:53 GMT
Subject: RFR: 8286182: C2: crash with SIGFPE when executing compiled code
In-Reply-To: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
References: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
Message-ID: <R3gueHmpJ4sxEbwH5zdN5fjn09o_UJfaZx2IngxxnPo=.cbd9228d-9174-4959-84df-8c5ddb57047d@github.com>

On Wed, 18 May 2022 15:44:10 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above their validity checks.
> 
> Thanks.

Backout looks good except that you did not remove the test `test/hotspot/jtreg/compiler/integerArithmetic/TestDivision.java` which you've added here:
https://github.com/openjdk/jdk/commit/b4a85cdae14eee895a0de2f26a2ffdd62b72bebc#diff-4daba70b215edefe9fd70b24f1e1052a51effdd48a1809e2ce5a06bc21a755c5

It's just a correctness test, so it would be okay to leave it in. But I guess it's better to backout everything.

-------------

Changes requested by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8774

From stuefe at openjdk.java.net  Thu May 19 07:05:50 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 19 May 2022 07:05:50 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <MufMBz_4YPBASS5M7ZqphZBcRSJL1VrNQnsqEAIn30Y=.c5e1a8ce-8e78-4526-8283-9b4ef82c6dfa@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
 <MJKt4LfScjBzsqrbVdVpeBRqai7vP1uq0pvZqnYVp7Q=.1882c0a0-770e-4048-8a29-a1fb98c14bf4@github.com>
 <MufMBz_4YPBASS5M7ZqphZBcRSJL1VrNQnsqEAIn30Y=.c5e1a8ce-8e78-4526-8283-9b4ef82c6dfa@github.com>
Message-ID: <bFP17N-GapgIOJykZ_pkLEvCGrKwTnj9yBo9fHAQ_xg=.c817dbf2-21d0-4d92-adc1-f159e3726d43@github.com>

On Wed, 18 May 2022 18:10:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> @iklam yes I meant `Find the longest common prefix`. Fixed the comment.
>
> I'm not convinced the extra function makes the code more readable, but here it is. I can revert back if this is too much.

@jerboaa Feel free to go back to your original variant. This was only a proposal.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From duke at openjdk.java.net  Thu May 19 07:48:53 2022
From: duke at openjdk.java.net (zhw970623)
Date: Thu, 19 May 2022 07:48:53 GMT
Subject: Integrated: 8286462: Incorrect copyright year for
 src/java.base/share/classes/jdk/internal/vm/FillerObject.java
In-Reply-To: <89Lf5xlbDoqPUpi9dK24kvS3fP8DvZkw0cbKeCNDdbI=.935b15e6-8942-47d6-9b84-8319bcde2a86@github.com>
References: <89Lf5xlbDoqPUpi9dK24kvS3fP8DvZkw0cbKeCNDdbI=.935b15e6-8942-47d6-9b84-8319bcde2a86@github.com>
Message-ID: <hnKk5Wi-Xy5qA9RhVAzoAemVK4DiHT9cYFbmiNlU_TE=.613cd4e2-0100-44ff-b9f7-191441932018@github.com>

On Tue, 10 May 2022 14:58:28 GMT, zhw970623 <duke at openjdk.java.net> wrote:

> The copyright year of src/java.base/share/classes/jdk/internal/vm/FillerObject.java should be 2022.

This pull request has now been integrated.

Changeset: 022e7170
Author:    yyrrzhang <yyrrzhang at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/022e71704ce81d9b47624fb9fb93a4017dae62a0
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8286462: Incorrect copyright year for src/java.base/share/classes/jdk/internal/vm/FillerObject.java

Reviewed-by: jiefu

-------------

PR: https://git.openjdk.java.net/jdk/pull/8633

From sgehwolf at openjdk.java.net  Thu May 19 08:21:48 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 19 May 2022 08:21:48 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v2]
In-Reply-To: <bFP17N-GapgIOJykZ_pkLEvCGrKwTnj9yBo9fHAQ_xg=.c817dbf2-21d0-4d92-adc1-f159e3726d43@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <-HWWHEa8XoZOvDQ3zDoWEqoZjf_LMHOI48RKfnLU3S8=.a5214356-d1cd-460d-9200-69604f2fd2e1@github.com>
 <sjk6MUJlfbiZjO1Bwku41WYUFjclGiqP6oTnk4xyGos=.32e3db7f-31f9-4485-8d90-1c6fdc7eed90@github.com>
 <MJKt4LfScjBzsqrbVdVpeBRqai7vP1uq0pvZqnYVp7Q=.1882c0a0-770e-4048-8a29-a1fb98c14bf4@github.com>
 <MufMBz_4YPBASS5M7ZqphZBcRSJL1VrNQnsqEAIn30Y=.c5e1a8ce-8e78-4526-8283-9b4ef82c6dfa@github.com>
 <bFP17N-GapgIOJykZ_pkLEvCGrKwTnj9yBo9fHAQ_xg=.c817dbf2-21d0-4d92-adc1-f159e3726d43@github.com>
Message-ID: <tFgYOehlmvqyy43MLE2MrMvQjQmi50OFBSRVu3AJOPA=.d5c88a7a-9404-4911-8476-23fbb5a0d1bc@github.com>

On Thu, 19 May 2022 07:02:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I'm not convinced the extra function makes the code more readable, but here it is. I can revert back if this is too much.
>
> @jerboaa Feel free to go back to your original variant. This was only a proposal.

understood.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From kevinw at openjdk.java.net  Thu May 19 08:43:45 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:43:45 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <c0o1YvhNkDe026TrcGqKdFaH6G93AfyQCHvBLzGNf8s=.007721e9-d02c-4319-a562-c3296fed6bbf@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.sctp/share/classes/com/sun/nio/sctp/ShutdownNotification.java line 28:

> 26: 
> 27: /**
> 28:  * Notification emitted when a peers shutdowns the association.

Maybe: "...when a peer shuts down an association."
(could be "shuts down the association" if there is only ever one, but using "an" looks safe)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 08:50:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:50:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:

> 346: 
> 347:     /**
> 348:      * Returns the single non-abstract {@link Method} visible from

I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From njian at openjdk.java.net  Thu May 19 08:57:07 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Thu, 19 May 2022 08:57:07 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v6]
In-Reply-To: <-lS_36hGarJvCL26lgWyXJd-e2SuLD9g1wWL5PuoLXI=.5ddb3b74-493f-41df-8544-8a963c66fc5d@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
 <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
 <dKj9d0RwFCkNlTZZ7nFEBu4zl_Wjj5RwRmH7-4q4QXU=.c6086bbc-055c-41e1-ae50-47797aa74b70@github.com>
 <-lS_36hGarJvCL26lgWyXJd-e2SuLD9g1wWL5PuoLXI=.5ddb3b74-493f-41df-8544-8a963c66fc5d@github.com>
Message-ID: <K_d8mxRe3ERm28mTTJPCpJn0A6QaPjKmGGe3p4CwglQ=.eeb7f7e8-0949-4fae-b343-c88f83c66aa1@github.com>

On Wed, 18 May 2022 23:22:42 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Interesting. But AArch64 code does cover vector cases which just adds confusion.

`UsePopCountInsturction` is always true in AArch64. @XiaohongGong removed the `predicate` in aarch64 rules, and I think we can even remove the option check in match_rule_supported().

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From kevinw at openjdk.java.net  Thu May 19 09:02:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:02:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <gSIQ2U9H0PmGgCBlsc4SocQff7AauSX3jiC10z26SJQ=.af26181b-5c61-4ecc-b836-5e5cff2cc901@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/opto/graphKit.cpp line 3626:

> 3624: // The optional arguments are for specialized use by intrinsics:
> 3625: //  - If 'extra_slow_test' if not null is an extra condition for the slow-path.
> 3626: //  - If 'return_size_val', report the total object size to the caller.

"reports the total"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From xgong at openjdk.java.net  Thu May 19 09:06:17 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 19 May 2022 09:06:17 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v6]
In-Reply-To: <K_d8mxRe3ERm28mTTJPCpJn0A6QaPjKmGGe3p4CwglQ=.eeb7f7e8-0949-4fae-b343-c88f83c66aa1@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
 <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
 <dKj9d0RwFCkNlTZZ7nFEBu4zl_Wjj5RwRmH7-4q4QXU=.c6086bbc-055c-41e1-ae50-47797aa74b70@github.com>
 <-lS_36hGarJvCL26lgWyXJd-e2SuLD9g1wWL5PuoLXI=.5ddb3b74-493f-41df-8544-8a963c66fc5d@github.com>
 <K_d8mxRe3ERm28mTTJPCpJn0A6QaPjKmGGe3p4CwglQ=.eeb7f7e8-0949-4fae-b343-c88f83c66aa1@github.com>
Message-ID: <GEkr5JEJBDbr7hw8-YS9rUThicgzIpiB63aBQnORQ7o=.eedb7194-8e6c-45a9-8b54-94ff0937da88@github.com>

On Thu, 19 May 2022 08:53:31 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>>> LUT should be generated only if UsePopCountInsturction is false 
>> 
>> Should there be `!UsePopCountInsturction` check then?
>> 
>>> restrict the scope of flag to only scalar popcount operation
>> 
>> Interesting. But AArch64 code does cover vector cases which just adds confusion.
>
>> Interesting. But AArch64 code does cover vector cases which just adds confusion.
> 
> `UsePopCountInsturction` is always true in AArch64. @XiaohongGong removed the `predicate` in aarch64 rules, and I think we can even remove the option check in match_rule_supported().

Ok , I will remove the check for it. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From kevinw at openjdk.java.net  Thu May 19 09:09:50 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:09:50 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <A3yxKJkrz3h716ciAsbQHtiWg_y5gMtqLrMoDSxFTWE=.6e31ca1c-505c-4794-b1f0-622dc811388c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/interpreter/bytecodeUtils.cpp line 186:

> 184:   static const int _max_cause_detail = 5;
> 185: 
> 186:   // Merges the stack the given bci with the given stack. If there

"...the stack at the given bci..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From sgehwolf at openjdk.java.net  Thu May 19 09:10:49 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 19 May 2022 09:10:49 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
Message-ID: <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>

On Thu, 19 May 2022 05:53:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor hotspot gtest
>>  - Separate into function. Fix comment.
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 60:
> 
>> 58:         strncpy(buf, _mount_point, MAXPATHLEN);
>> 59:         buf[MAXPATHLEN-1] = '\0';
>> 60:         _path = os::strdup(buf);
> 
> Comment on the old code: why this cannot be simply
> 
> 
> _path = os::strdup(_mount_point);
> 
> 
> Also, all the strncat calls in this function seem problematic, and should be converted to stringStream for consistency.

Agreed. I've filed https://bugs.openjdk.java.net/browse/JDK-8287007 to track this. I'd like to limit the changes of this patch to a minimum. It seems orthogonal.

> What happens if cgroup_path is "/foo/bar" and _root is "/fo"?

With a mount path of `/bar` this ends up being `/bar/o/bar`. Pretty strange, but then again it's a bit of a contrived example as those paths come from `/proc` parsing. Anyway, this is code that got added with [JDK-8146115](https://bugs.openjdk.java.net/browse/JDK-8146115). It's not something I've written and to be honest, I'm not sure this branch is needed, but I didn't want to change the existing behaviour with this patch. I have no more insight than you in terms of why that approach has been taken.

> Maybe this block should be combined with the new `else` block you're adding?

Maybe, but I'm not sure if it would break something.

> However, the behavior seems opposite between these two blocks of code:
> 
> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path
> 
> ```
>   TestCase substring_match = {
>     "/sys/fs/cgroup/memory",                           // mount_path
>     "/user.slice/user-1000.slice",                     // root_path
>     "/user.slice/user-1000.slice/user at 1001.service",   // cgroup_path
>     "/sys/fs/cgroup/memory/user at 1001.service"          // expected_path
>   };
> ```

Yes. Though, I cannot comment on why that has been chosen. It's been there since day one :-/

> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path
> 
> ```
>  TestCase prefix_matched_cg = {
>     "/sys/fs/cgroup/memory",                           // mount_path
>     "/user.slice/user-1000.slice/session-50.scope",    // root_path
>     "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>     "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path
>   };
> ```
> 
> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function.

The reason why I've gone down the path of adding the head of cgroup_path is because of this document (in conjunction to what the user was observing on an affected system):
https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/

The user was observing paths as listed in the test:

"/user.slice/user-1000.slice/session-50.scope",    // root_path
"/user.slice/user-1000.slice/session-3.scope",     // cgroup_path

This very much looks like systemd managed. Given that and knowing that systemd adds processes into `scopes` or `services` and groups them via `slices` and also knowing that cgroups are hierarchical (i.e. limits of `/foo/bar` also apply to `/foo/bar/baz`), it seems likely that if there are any limits, then it'll be on `/user.slice/user-1000.slice` within the mounted controller. Unfortunately, I'm not able to reproduce this myself.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From kevinw at openjdk.java.net  Thu May 19 09:27:55 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:27:55 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <02e6mwqZ3ihNyJb4lBK-5WeIGMfiLMj3I8LpJPv4i8o=.3c56077b-54f0-4c4e-b031-5a000b9ea887@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/cds/filemap.cpp line 1914:

> 1912: 
> 1913:     // the current value of the pointers to be patched must be within this
> 1914:     // range (i.e., must be between the requested base address, and the of the current archive).

"the of the" ? 
Maybe "..and the address of the current archive",  or maybe it was a typo for "and that of the current archive".

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From sgehwolf at openjdk.java.net  Thu May 19 09:33:41 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 19 May 2022 09:33:41 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
Message-ID: <Lrot_Fnbdjdv045WS9jwgVZyBZgAB3Ndu1mjmiUVx1I=.8e30c076-badd-4b19-894d-0d7e558fdc61@github.com>

On Thu, 19 May 2022 06:00:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor hotspot gtest
>>  - Separate into function. Fix comment.
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 86:
> 
>> 84:           const char* cgroup_p = cgroup_path;
>> 85:           int last_slash = find_last_slash_pos(root_p, cgroup_p);
>> 86:           assert(last_slash >= 0, "not an absolute path?");
> 
> Are root_p and cgroup_p directly read from the /proc/xxx files. If so, do we validate the input to make sure they are absolute paths?
> 
> It seems like our code cannot handle trailing '/' in the input. If so, we should clear all trailing '/' from the input string. Then, in functions that process them, we should assert that they don't end with slash. See my comment in find_last_slash_pos().

Yes, those values come from `/proc/self/mountinfo` and `/proc/self/cgroup`. There is no validation being done. Then again, we only end up in this branch if the root path is not a substring of the cgroup path. In that case trailing slashes don't matter, since there would not be a character by character match earlier.

I'll add handling of trailing slashes and appropriate asserts where it makes sense.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From kevinw at openjdk.java.net  Thu May 19 09:35:42 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:35:42 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 84:

> 82: 
> 83:     /**
> 84:      * Create a Zip file that will result in an Zip64 Extra (EXT) header

"result in a Zip64..."

test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:

> 30: /*
> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
> 32:  * formatted individual sections in addition the main attributes tested

"in addition to the..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:41:57 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:41:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

test/jdk/java/net/InterfaceAddress/Equals.java line 81:

> 79:     /**
> 80:      * Returns an InterfaceAddress instance with its fields set the values
> 81:      * specificed.

probably a typo for "set to the values specified."

-------------

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From sgehwolf at openjdk.java.net  Thu May 19 09:49:07 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 19 May 2022 09:49:07 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
Message-ID: <7HeR1izA4CAi-Q989J7bEf5vyjguRveviD8rNOouYkY=.63efa7b6-d2c4-4a17-8659-02c62b63f250@github.com>

On Thu, 19 May 2022 05:58:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor hotspot gtest
>>  - Separate into function. Fix comment.
>
> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 102:
> 
>> 100:   for (int i = 0; *s1 == *s2 && *s1 != 0; i++) {
>> 101:     if (*s1 == '/') {
>> 102:       last_matching_slash_pos = i;
> 
> I found the behavior a little hard to understand. Is it intentional?
> 
> 
> "/cat/cow", "/cat/dog"    -> "/cat/"
> "/cat/",    "/cat/dog"    -> "/cat/"
> "/cat",     "/cat/dog"    -> "/"
> 
> 
> The name `find_last_slash_pos` doesn't properly describe the behavior. I thought about `find_common_path_prefix`, but that doesn't match the current behavior (for the 3rd case, the common path prefix is `"/cat"`).

It's supposed to find the common path prefix as you say. I'll fix it. Open to suggestions to make it easier to understand.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From shade at openjdk.java.net  Thu May 19 09:49:54 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 May 2022 09:49:54 GMT
Subject: RFR: 8286956: Loom: Define test groups for development/porting use
In-Reply-To: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
References: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
Message-ID: <PpbLy1Ao1Grm6c_tbKqkpmaB2MrCcjJptRSFgRW9p04=.46ce6ce4-6e48-4ab1-9160-069ee4a88e42@github.com>

On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work.
> 
> https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
> https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125
> 
> I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom`
>  - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom`

Thanks! Any other comments? I'd like Loom porters to have it sooner.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8765

From cstein at openjdk.java.net  Thu May 19 10:23:14 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 19 May 2022 10:23:14 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
Message-ID: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>

This PR adds an optional description accessor on `ToolProvider` interface.

This PR also adds short description for each of the listed tool:
- `jar`
- `javac`
- `javadoc`
- `javap` and `jdeps`
- `jlink` and `jmod`
- `jpackage`

-------------

Commit messages:
 - Add localized description for `jpackage`
 - Add localized description for `jlink` and `jmod`
 - Add localized description for `javap` and `jdeps`
 - Add localized description for `javadoc`
 - Add localized description for `jar`
 - Add localized description for `javac`
 - 8286654: Add an optional description accessor on ToolProvider interface

Changes: https://git.openjdk.java.net/jdk/pull/8772/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8772&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286654
  Stats: 115 lines in 19 files changed: 97 ins; 2 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8772.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8772/head:pull/8772

PR: https://git.openjdk.java.net/jdk/pull/8772

From jjg at openjdk.java.net  Thu May 19 10:23:16 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 19 May 2022 10:23:16 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
Message-ID: <hlEn3ZTHbWSOxF99IchuV-G64886D96b1n-pEs9zELk=.4ce40936-9982-4467-b424-c4a9e469824d@github.com>

On Wed, 18 May 2022 14:56:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds an optional description accessor on `ToolProvider` interface.
> 
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpackage`

Main issue is the one I raised at the beginning, about what grammatical form you should be using for the short description.

Also, is the description a phrase (probably not capitalized, and no terminating period) or a sentence (capitalized with a terminating period.)

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavacToolProvider.java line 30:

> 28: import com.sun.tools.javac.util.JavacMessages;
> 29: import java.io.PrintWriter;
> 30: import java.util.Optional;

at least in javac, we normally sort `java.*` and `javax.*` imports before other imports.

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 387:

> 385: 
> 386: javac.description=Read Java declarations and compile them into class files
> 387: 

for your general consideration, what grammatical style do you recommend here? Should it be 3rd person (Reads) instead of 2nd person (Read)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8772

From cstein at openjdk.java.net  Thu May 19 10:23:17 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 19 May 2022 10:23:17 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <hlEn3ZTHbWSOxF99IchuV-G64886D96b1n-pEs9zELk=.4ce40936-9982-4467-b424-c4a9e469824d@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
 <hlEn3ZTHbWSOxF99IchuV-G64886D96b1n-pEs9zELk=.4ce40936-9982-4467-b424-c4a9e469824d@github.com>
Message-ID: <M_RZg5YrQqFiI-a8faE0WLSBBtFxMctGkEN8SVEJX68=.58ab28f2-a0b5-44f9-9c72-c00c428fbf5d@github.com>

On Wed, 18 May 2022 21:47:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This PR adds an optional description accessor on `ToolProvider` interface.
>> 
>> This PR also adds short description for each of the listed tool:
>> - `jar`
>> - `javac`
>> - `javadoc`
>> - `javap` and `jdeps`
>> - `jlink` and `jmod`
>> - `jpackage`
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavacToolProvider.java line 30:
> 
>> 28: import com.sun.tools.javac.util.JavacMessages;
>> 29: import java.io.PrintWriter;
>> 30: import java.util.Optional;
> 
> at least in javac, we normally sort `java.*` and `javax.*` imports before other imports.

Sorted imports accordingly.

> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 387:
> 
>> 385: 
>> 386: javac.description=Read Java declarations and compile them into class files
>> 387: 
> 
> for your general consideration, what grammatical style do you recommend here? Should it be 3rd person (Reads) instead of 2nd person (Read)

I took the phrases in 2nd person style from https://docs.oracle.com/en/java/javase/18/docs/specs/man/ as templates, shortening some of them to around 80 characters for better fitting in standard terminal widths.

Perhaps, those texts should be used "as-is" as descriptions?
- 2nd person phrase-style
- lowercase start
- no terminating period
- no shortening

-------------

PR: https://git.openjdk.java.net/jdk/pull/8772

From cstein at openjdk.java.net  Thu May 19 10:23:18 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 19 May 2022 10:23:18 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <M_RZg5YrQqFiI-a8faE0WLSBBtFxMctGkEN8SVEJX68=.58ab28f2-a0b5-44f9-9c72-c00c428fbf5d@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
 <hlEn3ZTHbWSOxF99IchuV-G64886D96b1n-pEs9zELk=.4ce40936-9982-4467-b424-c4a9e469824d@github.com>
 <M_RZg5YrQqFiI-a8faE0WLSBBtFxMctGkEN8SVEJX68=.58ab28f2-a0b5-44f9-9c72-c00c428fbf5d@github.com>
Message-ID: <-ELlQEdCsVQaXYzAcWjtGVe_m6v3KQNdRNvoGoLdAg4=.ae788c95-4a29-41f4-892b-8816ada0796b@github.com>

On Thu, 19 May 2022 06:21:40 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 387:
>> 
>>> 385: 
>>> 386: javac.description=Read Java declarations and compile them into class files
>>> 387: 
>> 
>> for your general consideration, what grammatical style do you recommend here? Should it be 3rd person (Reads) instead of 2nd person (Read)
>
> I took the phrases in 2nd person style from https://docs.oracle.com/en/java/javase/18/docs/specs/man/ as templates, shortening some of them to around 80 characters for better fitting in standard terminal widths.
> 
> Perhaps, those texts should be used "as-is" as descriptions?
> - 2nd person phrase-style
> - lowercase start
> - no terminating period
> - no shortening

Took the phrases "as-is" from the overview site for the man pages: [Java? Development Kit Version 18 Tool Specifications](https://docs.oracle.com/en/java/javase/18/docs/specs/man/)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8772

From redestad at openjdk.java.net  Thu May 19 10:55:10 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 19 May 2022 10:55:10 GMT
Subject: RFR: 8287013: StringConcatFactory: remove short and byte
 mixers/prependers
Message-ID: <Mi149SNDBYdQof7inBBjDau2ukKhguKSfOZwM1lsLkU=.541b9da5-1f3b-41ca-a3a3-415a18b0acbf@github.com>

The current short and byte mixers and prependers simply delegate to the int variants. At the LambdaForm level the values has already been implicitly cast to int, so removing this indirection and directly adapting to call the int-based variants is possible.

This is a cleanup with minimal effect on bootstrap overhead and peak performance, since all the LF logic only deals with basic types (where byte and short and other subword primitives has been widened to ints anyhow).

-------------

Commit messages:
 - 8287013: StringConcatFactory: remove short and byte mixers/prependers

Changes: https://git.openjdk.java.net/jdk/pull/8786/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8786&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287013
  Stats: 87 lines in 2 files changed: 12 ins; 74 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8786/head:pull/8786

PR: https://git.openjdk.java.net/jdk/pull/8786

From jlaskey at openjdk.java.net  Thu May 19 11:07:47 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 19 May 2022 11:07:47 GMT
Subject: RFR: 8287013: StringConcatFactory: remove short and byte
 mixers/prependers
In-Reply-To: <Mi149SNDBYdQof7inBBjDau2ukKhguKSfOZwM1lsLkU=.541b9da5-1f3b-41ca-a3a3-415a18b0acbf@github.com>
References: <Mi149SNDBYdQof7inBBjDau2ukKhguKSfOZwM1lsLkU=.541b9da5-1f3b-41ca-a3a3-415a18b0acbf@github.com>
Message-ID: <eobwrvS_bcqGKI5oLoo_YBvjYpdZb0dYtxnFHFHaPh8=.53936427-b400-4a88-90de-4b4250e5e475@github.com>

On Thu, 19 May 2022 10:47:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The current short and byte mixers and prependers simply delegate to the int variants. At the LambdaForm level the values has already been implicitly cast to int, so removing this indirection and directly adapting to call the int-based variants is possible.
> 
> This is a cleanup with minimal effect on bootstrap overhead and peak performance, since all the LF logic only deals with basic types (where byte and short and other subword primitives has been widened to ints anyhow).

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8786

From zjx001202 at gmail.com  Thu May 19 12:17:57 2022
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 19 May 2022 20:17:57 +0800
Subject: Question: Is it possible to introduce ASCII coder for compact
 strings to optimize performance for ASCII compatible encoding?
In-Reply-To: <7e6c09aa-aa5b-0582-2090-614911a05fdc@oracle.com>
References: <CAJL5A3==dUzrHZoa6s=5rjmRrXvY0xM2Y8JRvChSco40qkVmRw@mail.gmail.com>
 <7e6c09aa-aa5b-0582-2090-614911a05fdc@oracle.com>
Message-ID: <CAJL5A3m2LvXffqbz2BjqcgJzUJb1bjT=pJwN78D6S=cENgLytw@mail.gmail.com>

Thank you very much for your work, it seems that the decoding speed of the
new version of JDK has been greatly improved.

However, `hasNegatives` still has a cost on my device. I tried removing the
call to hasNegatives in `String.encodeUTF8` based on JDK 17.0.3,
then I tested its performance through JMH. I ran the JMH benchmark on two
of my x86 machines (The CPU of one of the machines is Ryzen 7 3700X and the
other is Xeon W-2175)
and got about a 20% performance boost on both machines.

Of course, The decoding performance in the new JDK is better than I
thought. For an ASCII string of length 10000, hasNegatives takes about 150
nanoseconds, and the duration increases linearly with the length.
Considering that these operations usually accompany IO, the overhead is
really not as noticeable as I thought.

Thank you again for your contribution to OpenJDK and your patience in
replying.

On Wed, May 18, 2022 at 10:47 PM Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi,
>
> so your suggestion is that String::coder would be ASCII if all
> codepoints are 0-127, then LATIN1 if it contains at least one char in
> the 128-255 range, otherwise UTF16? As you say this would mean we could
> skip scanning StringCoding::hasNegatives scans and similar overheads
> when converting known-to-be-ASCII Strings to UTF-8 and other ASCII
> compatible encoding. But it might also complicate logic in various
> places, so we need a clear win to motivate such work.
>
> So the first question to answer might be how much does the hasNegatives
> calls cost us. Depending on your hardware (and JDK version) the answer
> might be "almost nothing"!
>
> I did some work last year to speed up encoding and decoding ASCII-only
> data to/from various encodings. When I was done there was no longer much
> of a difference when encoding from String to an ASCII-compatible charset
> [1]. Maybe a scaling ~10% advantage for latin-1 in some microbenchmark
> when decoding on really large strings[2].
>
> But with the suggested change the decoding advantage would likely
> disappear: we maintain the invariant that Strings are equals if and only
> if their coders are equal, so no we'd now have to scan latin-1 encoded
> streams for non-ASCII bytes to disambiguate between ASCII and LATIN1.
>
> Maybe there are some other case that would be helped, but with some
> likely negatives and only a modest potential win then my gut feeling is
> that this wouldn't pay off.
>
> Best regards
> Claes
>
> [1] https://cl4es.github.io/2021/10/17/Faster-Charset-Encoding.html
> [2] https://cl4es.github.io/2021/02/23/Faster-Charset-Decoding.html
>
> (All the improvements discussed in the blog entires should be available
> since 17.0.2.)
>
> On 2022-05-18 14:07, Glavo wrote:
> > After the introduction of compact strings in Java 9, the current String
> may
> > store byte arrays encoded as Latin1 or UTF-16.
> > Here's a troublesome thing: Latin1 is not compatible with UTF-8. Not all
> > Latin1 byte strings are legal UTF-8 byte strings:
> > They are only compatible within the ASCII range, when there are code
> points
> > greater than 127, Latin1 uses a one-byte
> > representation, while UTF-8 requires two bytes.
> >
> > As an example, every time `JavaLangAccess::getBytesNoRepl` is called to
> > convert a string to a UTF-8 array,
> > the internal implementation needs to call `StringCoding.hasNegatives` to
> > scan the content byte array to determine that
> > the string can be encoded in ASCII, and thus eliminate array copies.
> > Similar steps are performed when calling `str.getBytes(UTF_8)`.
> >
> > So, is it possible to introduce a third possible value for
> `String::coder`:
> > ASCII?
> > This looks like an attractive option, and if we do this, we can introduce
> > fast paths for many methods.
> >
> > Of course, I know that this change is not completely free, and some
> methods
> > may bring slight performance
> > degradation due to the need to judge the coder, in particular, there may
> be
> > an impact on the performance of the
> > StringBuilder/StringBuffer. However, given that UTF-8 is by far the most
> > commonly used file encoding, the performance
> > benefits of fast paths are likely to cover more scenarios. In addition to
> > this, other ASCII compatible encodings may
> > also benefit, such as GB18030(GBK), or ISO 8859 variants. And if frozen
> > arrays were introduced into the JDK,
> > there would be more scenarios to enjoy performance improvements.
> >
> > So I would like to ask, is it possible for JDK to improve String storage
> in
> > a similar way in the future?
> > Has anyone explored this issue before?
> >
> > Sorry to bother you all, but I'm very much looking forward to the answer
> to
> > this question.
>

From duke at openjdk.java.net  Thu May 19 13:33:45 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 19 May 2022 13:33:45 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v2]
In-Reply-To: <gUkNSaRAvKgA4xrYcfTC3VDcsmGecJYwO2JTagqT0cY=.2a52339a-0f02-4ad8-a14f-7aa8d1f1736f@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <gUkNSaRAvKgA4xrYcfTC3VDcsmGecJYwO2JTagqT0cY=.2a52339a-0f02-4ad8-a14f-7aa8d1f1736f@github.com>
Message-ID: <sVrtUx_nRtiTaOZFeVZLihReGdIb0EAfgDFMOqKWH_E=.6a1cc9c4-39b2-4ab5-a418-ad24678c1427@github.com>

On Thu, 21 Apr 2022 03:44:18 GMT, liach <duke at openjdk.java.net> wrote:

>> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
>> 
>> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't need to complexify module cache

Can anyone, such as Mandy, review this cleanup?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From claes.redestad at oracle.com  Thu May 19 13:40:09 2022
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 19 May 2022 15:40:09 +0200
Subject: Question: Is it possible to introduce ASCII coder for compact
 strings to optimize performance for ASCII compatible encoding?
In-Reply-To: <CAJL5A3m2LvXffqbz2BjqcgJzUJb1bjT=pJwN78D6S=cENgLytw@mail.gmail.com>
References: <CAJL5A3==dUzrHZoa6s=5rjmRrXvY0xM2Y8JRvChSco40qkVmRw@mail.gmail.com>
 <7e6c09aa-aa5b-0582-2090-614911a05fdc@oracle.com>
 <CAJL5A3m2LvXffqbz2BjqcgJzUJb1bjT=pJwN78D6S=cENgLytw@mail.gmail.com>
Message-ID: <921f63c2-5919-ae17-d864-3f57ba97a9ef@oracle.com>

Yes, I think 20% is close to an upper bound, with less gain on smaller
strings due improved cache-locality. And as you say such a small
speed-up might not be very noticeable in practice when I/O is involved.

/Claes

On 2022-05-19 14:17, Glavo wrote:
> Thank you very much for your work, it seems that the decoding speed of 
> the new version of JDK has been greatly improved.
> 
> However, `hasNegatives` still has a cost on my device. I tried removing 
> the call to hasNegatives in `String.encodeUTF8` based on JDK 17.0.3,
> then I tested its performance through JMH.?I ran the JMH benchmark on 
> two of my x86 machines (The CPU of one of the machines is Ryzen 7 3700X 
> and the other is Xeon W-2175)
> and got about a 20% performance boost on both machines.
> 
> Of course, The decoding performance in the new JDK is better than I 
> thought. For an ASCII string of length 10000, hasNegatives takes about 
> 150 nanoseconds, and the duration increases linearly with the length.
> Considering that these operations usually accompany IO, the overhead is 
> really not as noticeable as I thought.
> 
> Thank you again for your contribution to OpenJDK and your patience in 
> replying.
> 
> On Wed, May 18, 2022 at 10:47 PM Claes Redestad 
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
> 
>     Hi,
> 
>     so your suggestion is that String::coder would be ASCII if all
>     codepoints are 0-127, then LATIN1 if it contains at least one char in
>     the 128-255 range, otherwise UTF16? As you say this would mean we could
>     skip scanning StringCoding::hasNegatives scans and similar overheads
>     when converting known-to-be-ASCII Strings to UTF-8 and other ASCII
>     compatible encoding. But it might also complicate logic in various
>     places, so we need a clear win to motivate such work.
> 
>     So the first question to answer might be how much does the hasNegatives
>     calls cost us. Depending on your hardware (and JDK version) the answer
>     might be "almost nothing"!
> 
>     I did some work last year to speed up encoding and decoding ASCII-only
>     data to/from various encodings. When I was done there was no longer much
>     of a difference when encoding from String to an ASCII-compatible charset
>     [1]. Maybe a scaling ~10% advantage for latin-1 in some microbenchmark
>     when decoding on really large strings[2].
> 
>     But with the suggested change the decoding advantage would likely
>     disappear: we maintain the invariant that Strings are equals if and only
>     if their coders are equal, so no we'd now have to scan latin-1 encoded
>     streams for non-ASCII bytes to disambiguate between ASCII and LATIN1.
> 
>     Maybe there are some other case that would be helped, but with some
>     likely negatives and only a modest potential win then my gut feeling is
>     that this wouldn't pay off.
> 
>     Best regards
>     Claes
> 
>     [1] https://cl4es.github.io/2021/10/17/Faster-Charset-Encoding.html
>     <https://urldefense.com/v3/__https://cl4es.github.io/2021/10/17/Faster-Charset-Encoding.html__;!!ACWV5N9M2RV99hQ!I_AH1iAOysINPqrZ3OaqijBHyoZwpzC_5jUnQk-lTGa8-V3RL6CnY8WP3t__jWfDKrUylGMS6E5NEBW7JwNo$>
>     [2] https://cl4es.github.io/2021/02/23/Faster-Charset-Decoding.html
>     <https://urldefense.com/v3/__https://cl4es.github.io/2021/02/23/Faster-Charset-Decoding.html__;!!ACWV5N9M2RV99hQ!I_AH1iAOysINPqrZ3OaqijBHyoZwpzC_5jUnQk-lTGa8-V3RL6CnY8WP3t__jWfDKrUylGMS6E5NEDHadwAE$>
> 
>     (All the improvements discussed in the blog entires should be available
>     since 17.0.2.)
> 
>     On 2022-05-18 14:07, Glavo wrote:
>      > After the introduction of compact strings in Java 9, the current
>     String may
>      > store byte arrays encoded as Latin1 or UTF-16.
>      > Here's a troublesome thing: Latin1 is not compatible with UTF-8.
>     Not all
>      > Latin1 byte strings are legal UTF-8 byte strings:
>      > They are only compatible within the ASCII range, when there are
>     code points
>      > greater than 127, Latin1 uses a one-byte
>      > representation, while UTF-8 requires two bytes.
>      >
>      > As an example, every time `JavaLangAccess::getBytesNoRepl` is
>     called to
>      > convert a string to a UTF-8 array,
>      > the internal implementation needs to call
>     `StringCoding.hasNegatives` to
>      > scan the content byte array to determine that
>      > the string can be encoded in ASCII, and thus eliminate array copies.
>      > Similar steps are performed when calling `str.getBytes(UTF_8)`.
>      >
>      > So, is it possible to introduce a third possible value for
>     `String::coder`:
>      > ASCII?
>      > This looks like an attractive option, and if we do this, we can
>     introduce
>      > fast paths for many methods.
>      >
>      > Of course, I know that this change is not completely free, and
>     some methods
>      > may bring slight performance
>      > degradation due to the need to judge the coder, in particular,
>     there may be
>      > an impact on the performance of the
>      > StringBuilder/StringBuffer. However, given that UTF-8 is by far
>     the most
>      > commonly used file encoding, the performance
>      > benefits of fast paths are likely to cover more scenarios. In
>     addition to
>      > this, other ASCII compatible encodings may
>      > also benefit, such as GB18030(GBK), or ISO 8859 variants. And if
>     frozen
>      > arrays were introduced into the JDK,
>      > there would be more scenarios to enjoy performance improvements.
>      >
>      > So I would like to ask, is it possible for JDK to improve String
>     storage in
>      > a similar way in the future?
>      > Has anyone explored this issue before?
>      >
>      > Sorry to bother you all, but I'm very much looking forward to the
>     answer to
>      > this question.
> 

From rriggs at openjdk.java.net  Thu May 19 14:36:43 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 May 2022 14:36:43 GMT
Subject: RFR: 8267038: Update IANA Language Subtag Registry to Version
 2022-03-02
In-Reply-To: <CZtyBskEU020ETi-1KB0QPOyM1lQ5R0ea86nclLAac0=.626db933-7d76-4307-83a4-6217471bcb64@github.com>
References: <CZtyBskEU020ETi-1KB0QPOyM1lQ5R0ea86nclLAac0=.626db933-7d76-4307-83a4-6217471bcb64@github.com>
Message-ID: <vHEpl5VNBqnHKo-hLm9uQ6bGmYFpaVBif1PlGqmxsfw=.cd4c8cce-21b6-4e59-9d32-662dd172d899@github.com>

On Wed, 18 May 2022 16:28:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to incorporate the latest language subtag registry definition (version 2022-03-02) into JDK19.

Looks fine.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8776

From xuelei at openjdk.java.net  Thu May 19 14:58:48 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:48 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <AEcXIgzPrzjMIYqVKaZBv2j_3w8nrjL-kejrZ0nvBGE=.cb7c63c7-8f32-4cfa-b7d5-e2bb84750add@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

The security/crypto parts look good to me.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From xuelei at openjdk.java.net  Thu May 19 14:58:49 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:49 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
In-Reply-To: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
Message-ID: <lPlIgFLf96r_Xr7YJIr2w2uODPCG9bRPhAnl2tuAo50=.82a145da-9923-4c5b-a72d-14ba982bf303@github.com>

On Thu, 19 May 2022 09:31:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> Also, I fixed a couple of spelling mistakes.
>
> test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:
> 
>> 30: /*
>> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
>> 32:  * formatted individual sections in addition the main attributes tested
> 
> "in addition to the..."

+1.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From duke at openjdk.java.net  Thu May 19 15:29:29 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 19 May 2022 15:29:29 GMT
Subject: RFR: 8286182: C2: crash with SIGFPE when executing compiled code
 [v2]
In-Reply-To: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
References: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
Message-ID: <EiRIuFAuurs35tRF4S-oZoLukhWM9ZS37QD795YJ7K0=.96dcd475-94d9-4f1e-97ce-98b5f9b8ebfa@github.com>

> This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above their validity checks.
> 
> Thanks.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  Remove added test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8774/files
  - new: https://git.openjdk.java.net/jdk/pull/8774/files/bf963e6b..1e2f12d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8774&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8774&range=00-01

  Stats: 99 lines in 1 file changed: 0 ins; 99 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8774.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8774/head:pull/8774

PR: https://git.openjdk.java.net/jdk/pull/8774

From jbhateja at openjdk.java.net  Thu May 19 15:37:29 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 19 May 2022 15:37:29 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v3]
In-Reply-To: <rWRoQRmRyI6tQ4SeZo1qC9Pbc201-YytIVrGX3wBJ9E=.e364352d-f6af-48f9-bf86-dc27fa977468@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
 <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
 <Sbf6Rj5Zz8KFJIGpJmdMH9ScVs3CeKgINDk4d8L-nNc=.e259a479-e03f-445a-a641-413fe0183ec8@github.com>
 <rWRoQRmRyI6tQ4SeZo1qC9Pbc201-YytIVrGX3wBJ9E=.e364352d-f6af-48f9-bf86-dc27fa977468@github.com>
Message-ID: <JOyBytPc5GKq_P9rwPd25FihD9m7AfnXEAjWxsj9GRQ=.29caa4ec-dcb5-4b9e-9e30-dbb1cac6c986@github.com>

On Wed, 18 May 2022 23:28:22 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Its more of a chicken-egg problem here, for masked reverse operation, Reverse IR node is followed by a Blend Node, thus in such a case doing an eager Identity transform in Reverse::Identity will not work, also deferring this to blend may also not work since it could be a non-masked reverse operation, we could have handled it as a special case in inline_vector_nary_operation, but handling such special case in final graph reshaping looked more appropriate.
>> 
>> https://github.com/openjdk/panama-vector/pull/182#discussion_r845678080
>
> Do you mean it's important to apply the transformation at the right node (pick the right node as the root) and it is hard to make a decision during GVN?

Yes, that what I meant.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From jbhateja at openjdk.java.net  Thu May 19 15:41:19 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 19 May 2022 15:41:19 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v3]
In-Reply-To: <rWRoQRmRyI6tQ4SeZo1qC9Pbc201-YytIVrGX3wBJ9E=.e364352d-f6af-48f9-bf86-dc27fa977468@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
 <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
 <Sbf6Rj5Zz8KFJIGpJmdMH9ScVs3CeKgINDk4d8L-nNc=.e259a479-e03f-445a-a641-413fe0183ec8@github.com>
 <rWRoQRmRyI6tQ4SeZo1qC9Pbc201-YytIVrGX3wBJ9E=.e364352d-f6af-48f9-bf86-dc27fa977468@github.com>
Message-ID: <QSKQscTFsh4TUBdJomlFZznHiVOMSGG0B5hkOanRYXU=.86f00e4d-ea19-4c88-8e6f-701b87ae3b7d@github.com>

On Wed, 18 May 2022 23:35:54 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> It was an attempt to facilitate in-lining of these APIs over targets which do not intrinsify them. I agree its not a generic fix since three APIs are piggybacking on same entry point and without the knowledge of opcode it will be inappropriate to take any call at this place, lazy intrinsification gives opportunity for some of the predications to concertize as compilation happens under closed world assumptions.
>
> Still not clear why the code is shaped the way it is.
> 
> `Matcher::match_rule_supported_vector()` already checks that there are relevant matching rules.
> 
> The checks require both `CompressM` and `CompressV` to be present to enable the intrinsic. Is it important?
> 
> Also, it doesn't take `EnableVectorSupport` into account while all other vector intrinsics respect it.

Yes, the code was modified to accommodate your comments. 
https://github.com/openjdk/jdk/pull/8425/files#diff-a9dd7e411772c1ee37b54c5ab868a01fe82af905758350f0ba1c370f422c3fe6R718

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From darcy at openjdk.java.net  Thu May 19 15:53:53 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 19 May 2022 15:53:53 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
Message-ID: <N4kdb-3lUkKifHbm_WTwVC6QMy0xz24f0nONPj_c4Go=.dbec1895-2e88-4ed4-ae23-ccb3717902c4@github.com>

On Wed, 18 May 2022 14:56:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds an optional description accessor on `ToolProvider` interface.
> 
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpackage`

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8772

From duke at openjdk.java.net  Thu May 19 16:01:35 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 19 May 2022 16:01:35 GMT
Subject: RFR: 8202449: overflow handling in Random.doubles
Message-ID: <6OZGdr2SP8kDv1jsxupgndb3Lsbe62CQLlvhgHZNQAo=.1777192e-ba14-4bcc-9fea-a6a06d66543b@github.com>

Extend the range of Random.doubles(double, double) and similar methods.

-------------

Commit messages:
 - 8202449: overflow handling in Random.doubles

Changes: https://git.openjdk.java.net/jdk/pull/8791/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8791&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8202449
  Stats: 108 lines in 4 files changed: 47 ins; 25 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8791.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8791/head:pull/8791

PR: https://git.openjdk.java.net/jdk/pull/8791

From duke at openjdk.java.net  Thu May 19 16:02:50 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 19 May 2022 16:02:50 GMT
Subject: RFR: 8286182: [BACKOUT] x86: Handle integral division overflow
 during parsing [v2]
In-Reply-To: <EiRIuFAuurs35tRF4S-oZoLukhWM9ZS37QD795YJ7K0=.96dcd475-94d9-4f1e-97ce-98b5f9b8ebfa@github.com>
References: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
 <EiRIuFAuurs35tRF4S-oZoLukhWM9ZS37QD795YJ7K0=.96dcd475-94d9-4f1e-97ce-98b5f9b8ebfa@github.com>
Message-ID: <-aUyz0xzTc007JIqF5ofVTUBynH6Q32BR3OD9T7qP28=.2e6a1b38-d36a-4d54-a570-03806a4cc5cb@github.com>

On Thu, 19 May 2022 15:29:29 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above their validity checks.
>> 
>> Thanks.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove added test

I have backed out also the division test and created JBS issues as instructed in the developer guide. Hope I have done it correctly. Thanks a lot for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8774

From duke at openjdk.java.net  Thu May 19 16:16:32 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 19 May 2022 16:16:32 GMT
Subject: RFR: 8202449: overflow handling in Random.doubles [v2]
In-Reply-To: <6OZGdr2SP8kDv1jsxupgndb3Lsbe62CQLlvhgHZNQAo=.1777192e-ba14-4bcc-9fea-a6a06d66543b@github.com>
References: <6OZGdr2SP8kDv1jsxupgndb3Lsbe62CQLlvhgHZNQAo=.1777192e-ba14-4bcc-9fea-a6a06d66543b@github.com>
Message-ID: <cQO_wNiaSnNPBf5FzDscJz3S7V1gnOZbf5Y-H3TPh04=.1c9ef66a-94b5-4835-af4b-c1062d4c0bac@github.com>

> Extend the range of Random.doubles(double, double) and similar methods.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8202449: overflow handling in Random.doubles

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8791/files
  - new: https://git.openjdk.java.net/jdk/pull/8791/files/936a5bc1..62322ac1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8791&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8791&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8791.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8791/head:pull/8791

PR: https://git.openjdk.java.net/jdk/pull/8791

From jjg at openjdk.java.net  Thu May 19 16:18:07 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 19 May 2022 16:18:07 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
Message-ID: <hf-SWZHrw3jYIJYNiqTkIhcgImjG-mDCDW9yLpwP0xM=.83a26877-1f78-4341-ab1d-cf4a59f083aa@github.com>

On Wed, 18 May 2022 14:56:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds an optional description accessor on `ToolProvider` interface.
> 
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpackage`

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8772

From lancea at openjdk.java.net  Thu May 19 16:18:09 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 May 2022 16:18:09 GMT
Subject: RFR: 8286654: Add an optional description accessor on ToolProvider
 interface
In-Reply-To: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
Message-ID: <VOI91dj04QvIFqK2rf7HX06_cCyg5sBSQa5afr9gkLY=.a80aeddb-ff8c-4287-bb48-9ea187e2682e@github.com>

On Wed, 18 May 2022 14:56:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds an optional description accessor on `ToolProvider` interface.
> 
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpackage`

Marked as reviewed by lancea (Reviewer).

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 28:

> 26: ## tool
> 27: 
> 28: jar.description=create an archive for classes and resources, and manipulate or restore individual classes or resources from an archive

Not sure I love the use of  _manipulate_ but I understand that this is the wording from the tools guide for jar.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8772

From cstein at openjdk.java.net  Thu May 19 18:28:47 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 19 May 2022 18:28:47 GMT
Subject: Integrated: 8286654: Add an optional description accessor on
 ToolProvider interface
In-Reply-To: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
References: <idu7ilcy7qCo_-M3B-3juGru4uSPmjFU5kgkl1ifJyc=.a182a193-1df5-4345-8fd8-b2ee68cf5c97@github.com>
Message-ID: <XcuML4Z4r0O8ohv_AVFE62qVcR-B23LcuCDiq_LqadQ=.64317df3-3e07-42b9-84c2-f1da946384c8@github.com>

On Wed, 18 May 2022 14:56:47 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This PR adds an optional description accessor on `ToolProvider` interface.
> 
> This PR also adds short description for each of the listed tool:
> - `jar`
> - `javac`
> - `javadoc`
> - `javap` and `jdeps`
> - `jlink` and `jmod`
> - `jpackage`

This pull request has now been integrated.

Changeset: 655500a4
Author:    Christian Stein <cstein at openjdk.org>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/655500a4f5e3abcff176599604deceefb6ca6640
Stats:     115 lines in 19 files changed: 97 ins; 2 del; 16 mod

8286654: Add an optional description accessor on ToolProvider interface

Reviewed-by: jjg, darcy, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8772

From naoto at openjdk.java.net  Thu May 19 18:53:53 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 19 May 2022 18:53:53 GMT
Subject: Integrated: 8267038: Update IANA Language Subtag Registry to Version
 2022-03-02
In-Reply-To: <CZtyBskEU020ETi-1KB0QPOyM1lQ5R0ea86nclLAac0=.626db933-7d76-4307-83a4-6217471bcb64@github.com>
References: <CZtyBskEU020ETi-1KB0QPOyM1lQ5R0ea86nclLAac0=.626db933-7d76-4307-83a4-6217471bcb64@github.com>
Message-ID: <2GtR8PtSUO2KoohdPPb-jv8JDbbnD2IYVo_VEdR-BJs=.64dfaf2d-d04f-4e96-8ca5-08940b8ac4ee@github.com>

On Wed, 18 May 2022 16:28:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to incorporate the latest language subtag registry definition (version 2022-03-02) into JDK19.

This pull request has now been integrated.

Changeset: 7b19226b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b19226be24356572df493446e3b0a9380b3d217
Stats:     281 lines in 2 files changed: 271 ins; 2 del; 8 mod

8267038: Update IANA Language Subtag Registry to Version 2022-03-02

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8776

From aivanov at openjdk.java.net  Thu May 19 18:54:04 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:54:04 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <De1XJE92ZHSiL99Rs-yvnD30-uzxuj4sfIn432JAocM=.2d3d0f7a-8c35-4575-aa20-1ccc267021c4@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:

 - ...set to the values...
 - ...will result in a Zip64 Extra (EXT) header
 - ...in addition to the main attributes...
 - ...and the address of the current archive
 - Merges the stack at the given bci...
 - Returns a single ...
 - ...when a peer shuts down an association.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/c7e73658..0669cdc1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Thu May 19 18:59:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:59:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <ofLOdFL_F4p6Dprc1UrQ-jmEYy8hlxKGB_GfEOayInY=.1a91952d-c387-4de3-b284-d96979c7f4dd@github.com>
Message-ID: <bBFati7RKtrl5FcrKP4_YCSO34DZrrIX7b_Daw9f91E=.dbbf28d9-92ef-4ae1-950c-f34036d483e4@github.com>

On Thu, 19 May 2022 08:47:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:
> 
>> 346: 
>> 347:     /**
>> 348:      * Returns the single non-abstract {@link Method} visible from
> 
> I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

I've accepted it, yet I'm still unsure whether ?a? or ?the??

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Thu May 19 19:06:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 19:06:56 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v2]
In-Reply-To: <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
 <ffzgOk9CFD-OUCvFHZbkgwP52r-bAGtYKNu96Vt9lGs=.6bcba275-c5e3-44b0-9f81-fe6e74a44e85@github.com>
Message-ID: <Hm4DXlPz0QuS87RjrcFEwxyh-97burW3YzckN3z0aGM=.6c816cc2-3256-4b2c-87d7-c2206b9f9a39@github.com>

On Thu, 19 May 2022 09:38:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

Thank you @kevinjwalls for your suggestions. I've incorporated them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From duke at openjdk.java.net  Thu May 19 19:15:52 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 19 May 2022 19:15:52 GMT
Subject: Integrated: 8286182: [BACKOUT] x86: Handle integral division overflow
 during parsing
In-Reply-To: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
References: <SXWoGmHjWpp30JtMVKgWn49ze4h30iK1Ps4XdkXIkSc=.e7e86378-596e-428d-9b80-1e288a1be174@github.com>
Message-ID: <Qx4scaSX7DuTb8kipZ8Qa5smcaOHoLBBeKc7X5psXSI=.cf47978f-0a4e-4a14-a872-da3baba3c37c@github.com>

On Wed, 18 May 2022 15:44:10 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above their validity checks.
> 
> Thanks.

This pull request has now been integrated.

Changeset: 079312c8
Author:    Quan Anh Mai <anhmdq99 at gmail.com>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/079312c835a75e2ed5329d061583add5ac9fa2e0
Stats:     1065 lines in 25 files changed: 364 ins; 575 del; 126 mod

8286182: [BACKOUT] x86: Handle integral division overflow during parsing
8287035: [BACKOUT] PPC64: Handle integral division overflow during parsing

Reviewed-by: mdoerr, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/8774

From iklam at openjdk.java.net  Thu May 19 20:02:36 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 19 May 2022 20:02:36 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
 <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>
Message-ID: <bPoDNxABi63JebXkYflJ3FUR0IF8OieXLmwkwjIxmk8=.1651330e-59af-4f56-932e-08d37626dfe9@github.com>

On Thu, 19 May 2022 09:06:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 63:
>> 
>>> 61:       } else {
>>> 62:         char *p = strstr(cgroup_path, _root);
>>> 63:         if (p != NULL && p == cgroup_path) {
>> 
>> What happens if cgroup_path is "/foo/bar" and _root is "/fo"?
>> 
>> Maybe this block should be combined with the new `else` block you're adding? However, the behavior seems opposite between these two blocks of code:
>> 
>> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path
>> 
>> 
>>   TestCase substring_match = {
>>     "/sys/fs/cgroup/memory",                           // mount_path
>>     "/user.slice/user-1000.slice",                     // root_path
>>     "/user.slice/user-1000.slice/user at 1001.service",   // cgroup_path
>>     "/sys/fs/cgroup/memory/user at 1001.service"          // expected_path
>>   };
>> 
>> 
>> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path
>> 
>> 
>>  TestCase prefix_matched_cg = {
>>     "/sys/fs/cgroup/memory",                           // mount_path
>>     "/user.slice/user-1000.slice/session-50.scope",    // root_path
>>     "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>>     "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path
>>   };
>> 
>> 
>> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function.
>
>> What happens if cgroup_path is "/foo/bar" and _root is "/fo"?
> 
> With a mount path of `/bar` this ends up being `/bar/o/bar`. Pretty strange, but then again it's a bit of a contrived example as those paths come from `/proc` parsing. Anyway, this is code that got added with [JDK-8146115](https://bugs.openjdk.java.net/browse/JDK-8146115). It's not something I've written and to be honest, I'm not sure this branch is needed, but I didn't want to change the existing behaviour with this patch. I have no more insight than you in terms of why that approach has been taken.
> 
>> Maybe this block should be combined with the new `else` block you're adding?
> 
> Maybe, but I'm not sure if it would break something.
> 
>> However, the behavior seems opposite between these two blocks of code:
>> 
>> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path
>> 
>> ```
>>   TestCase substring_match = {
>>     "/sys/fs/cgroup/memory",                           // mount_path
>>     "/user.slice/user-1000.slice",                     // root_path
>>     "/user.slice/user-1000.slice/user at 1001.service",   // cgroup_path
>>     "/sys/fs/cgroup/memory/user at 1001.service"          // expected_path
>>   };
>> ```
> 
> Yes. Though, I cannot comment on why that has been chosen. It's been there since day one :-/
> 
>> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path
>> 
>> ```
>>  TestCase prefix_matched_cg = {
>>     "/sys/fs/cgroup/memory",                           // mount_path
>>     "/user.slice/user-1000.slice/session-50.scope",    // root_path
>>     "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>>     "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path
>>   };
>> ```
>> 
>> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function.
> 
> The reason why I've gone down the path of adding the head of cgroup_path is because of this document (in conjunction to what the user was observing on an affected system):
> https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> 
> The user was observing paths as listed in the test:
> 
> "/user.slice/user-1000.slice/session-50.scope",    // root_path
> "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
> 
> This very much looks like systemd managed. Given that and knowing that systemd adds processes into `scopes` or `services` and groups them via `slices` and also knowing that cgroups are hierarchical (i.e. limits of `/foo/bar` also apply to `/foo/bar/baz`), it seems likely that if there are any limits, then it'll be on `/user.slice/user-1000.slice` within the mounted controller. Unfortunately, I'm not able to reproduce this myself.

I am wondering if the problem is this:

We have systemd running on the host, and a different copy of systemd that runs inside the container.

- They both set up `/user.slice/user-1000.slice/session-??.scope` within their own file systems
- For some reason, when you're looking inside the container, `/proc/self/cgroup` might use a path in the containerized file system whereas `/proc/self/mountinfo` uses a path in the host file system. These two paths may look alike but they have absolutely no relation to each other.

I have asked the reporter for more information:

https://gist.github.com/gaol/4d96eace8290e6549635fdc0ea41d0b4?permalink_comment_id=4172593#gistcomment-4172593

Meanwhile, I think the current method of finding "which directory under /sys/fs/cgroup/memory controls my memory usage" is broken. As mentioned about, the path you get from  `/proc/self/cgroup`  and `/proc/self/mountinfo` have no relation to each other, but we use them anyway to get our answer, with many ad-hoc methods that are not documented in the code.

Maybe we should do this instead?

- Read /proc/self/cgroup
- Find the `10:memory:<path>` line
- If `/sys/fs/cgroup/memory/<path>/tasks` contains my PID, this is the path
- Otherwise, scan all `tasks` files under  `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID.

For example, here's a test with docker:


INSIDE CONTAINER
# cat /proc/self/cgroup | grep memory
10:memory:/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050
# cat /proc/self/mountinfo | grep memory
801 791 0:42 /docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime master:23 - cgroup cgroup rw,memory
# cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
cat: /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks: No such file or directory
# cat /sys/fs/cgroup/memory/tasks | grep $$
1

ON HOST
# cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
37494
# cat /proc/37494/status | grep NSpid
NSpid:	37494	1

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From mchung at openjdk.java.net  Thu May 19 20:10:45 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 19 May 2022 20:10:45 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v2]
In-Reply-To: <gUkNSaRAvKgA4xrYcfTC3VDcsmGecJYwO2JTagqT0cY=.2a52339a-0f02-4ad8-a14f-7aa8d1f1736f@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <gUkNSaRAvKgA4xrYcfTC3VDcsmGecJYwO2JTagqT0cY=.2a52339a-0f02-4ad8-a14f-7aa8d1f1736f@github.com>
Message-ID: <1Z4YXlbK0ovXQ5Q8quDX2LKmLNnAbe6e418fpNPBofY=.031a4844-a51b-42c9-b2ec-58cbe8737bac@github.com>

On Thu, 21 Apr 2022 03:44:18 GMT, liach <duke at openjdk.java.net> wrote:

>> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
>> 
>> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Don't need to complexify module cache

src/java.base/share/classes/java/lang/reflect/Proxy.java line 498:

> 496:             new ClassLoaderValue<>();
> 497: 
> 498:         private record ProxyContext(Module module, String pkg, boolean packagePrivate) {}

This represents the context for a proxy class.   It seems `ProxyClassContext` would be clearer.   I suggest the context to have the accessFlags for a proxy class rather than the boolean whether it's package private.   The constructor should check that it must be 0 or `Modifier.PUBLIC`.   `FINAL` will be added to the access flags when it generates the proxy class.

src/java.base/share/classes/java/lang/reflect/Proxy.java line 766:

> 764:          * Reads edge and qualified exports are added for dynamic module to access.
> 765:          */
> 766:         private static ProxyContext setupContext(ClassLoader loader,

Perhaps name this method `proxyClassContext` that returns `ProxyClassContext`.

src/java.base/share/classes/java/lang/reflect/Proxy.java line 831:

> 829:             // All proxy interfaces are public.  So maps to a dynamic proxy module
> 830:             // and add reads edge and qualified exports, if necessary
> 831:             var context = getDynamicModuleContext(loader, nonExported);

I suggest to keep the `getDynamicModule` method as creating a dynamic module of a given class loader is a clear function.   The context can be created in this method body.


            var targetModule = getDynamicModule(loader);
            var pkgName = nonExported ? PROXY_PACKAGE_PREFIX + '.' + targetModule.getName()
                                      : targetModule.getName();
            var context = new ProxyClassContext(targetModule, pkgName, Modifier.PUBLIC);

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From iklam at openjdk.java.net  Thu May 19 20:21:47 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 19 May 2022 20:21:47 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <bPoDNxABi63JebXkYflJ3FUR0IF8OieXLmwkwjIxmk8=.1651330e-59af-4f56-932e-08d37626dfe9@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
 <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>
 <bPoDNxABi63JebXkYflJ3FUR0IF8OieXLmwkwjIxmk8=.1651330e-59af-4f56-932e-08d37626dfe9@github.com>
Message-ID: <fRitJVBN5BS8dbJ0VvMDkFZ65xpDJvhd5KlCKk5DhMI=.ca576f15-5b74-48d3-b46a-1432780ad016@github.com>

On Thu, 19 May 2022 19:59:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> What happens if cgroup_path is "/foo/bar" and _root is "/fo"?
>> 
>> With a mount path of `/bar` this ends up being `/bar/o/bar`. Pretty strange, but then again it's a bit of a contrived example as those paths come from `/proc` parsing. Anyway, this is code that got added with [JDK-8146115](https://bugs.openjdk.java.net/browse/JDK-8146115). It's not something I've written and to be honest, I'm not sure this branch is needed, but I didn't want to change the existing behaviour with this patch. I have no more insight than you in terms of why that approach has been taken.
>> 
>>> Maybe this block should be combined with the new `else` block you're adding?
>> 
>> Maybe, but I'm not sure if it would break something.
>> 
>>> However, the behavior seems opposite between these two blocks of code:
>>> 
>>> The upper block: _root is a prefix of cgroup_path, we take the **tail** of cgroup_path
>>> 
>>> ```
>>>   TestCase substring_match = {
>>>     "/sys/fs/cgroup/memory",                           // mount_path
>>>     "/user.slice/user-1000.slice",                     // root_path
>>>     "/user.slice/user-1000.slice/user at 1001.service",   // cgroup_path
>>>     "/sys/fs/cgroup/memory/user at 1001.service"          // expected_path
>>>   };
>>> ```
>> 
>> Yes. Though, I cannot comment on why that has been chosen. It's been there since day one :-/
>> 
>>> The lower block: The beginning of _root is a prefix of cgroup_path, we take the **head** of cgroup_path
>>> 
>>> ```
>>>  TestCase prefix_matched_cg = {
>>>     "/sys/fs/cgroup/memory",                           // mount_path
>>>     "/user.slice/user-1000.slice/session-50.scope",    // root_path
>>>     "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>>>     "/sys/fs/cgroup/memory/user.slice/user-1000.slice" // expected_path
>>>   };
>>> ```
>>> 
>>> I find the behavior hard to understand. I think the rules (and reasons) should be added to the comment block above the function.
>> 
>> The reason why I've gone down the path of adding the head of cgroup_path is because of this document (in conjunction to what the user was observing on an affected system):
>> https://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
>> 
>> The user was observing paths as listed in the test:
>> 
>> "/user.slice/user-1000.slice/session-50.scope",    // root_path
>> "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>> 
>> This very much looks like systemd managed. Given that and knowing that systemd adds processes into `scopes` or `services` and groups them via `slices` and also knowing that cgroups are hierarchical (i.e. limits of `/foo/bar` also apply to `/foo/bar/baz`), it seems likely that if there are any limits, then it'll be on `/user.slice/user-1000.slice` within the mounted controller. Unfortunately, I'm not able to reproduce this myself.
>
> I am wondering if the problem is this:
> 
> We have systemd running on the host, and a different copy of systemd that runs inside the container.
> 
> - They both set up `/user.slice/user-1000.slice/session-??.scope` within their own file systems
> - For some reason, when you're looking inside the container, `/proc/self/cgroup` might use a path in the containerized file system whereas `/proc/self/mountinfo` uses a path in the host file system. These two paths may look alike but they have absolutely no relation to each other.
> 
> I have asked the reporter for more information:
> 
> https://gist.github.com/gaol/4d96eace8290e6549635fdc0ea41d0b4?permalink_comment_id=4172593#gistcomment-4172593
> 
> Meanwhile, I think the current method of finding "which directory under /sys/fs/cgroup/memory controls my memory usage" is broken. As mentioned about, the path you get from  `/proc/self/cgroup`  and `/proc/self/mountinfo` have no relation to each other, but we use them anyway to get our answer, with many ad-hoc methods that are not documented in the code.
> 
> Maybe we should do this instead?
> 
> - Read /proc/self/cgroup
> - Find the `10:memory:<path>` line
> - If `/sys/fs/cgroup/memory/<path>/tasks` contains my PID, this is the path
> - Otherwise, scan all `tasks` files under  `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID.
> 
> For example, here's a test with docker:
> 
> 
> INSIDE CONTAINER
> # cat /proc/self/cgroup | grep memory
> 10:memory:/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050
> # cat /proc/self/mountinfo | grep memory
> 801 791 0:42 /docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime master:23 - cgroup cgroup rw,memory
> # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
> cat: /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks: No such file or directory
> # cat /sys/fs/cgroup/memory/tasks | grep $$
> 1
> 
> ON HOST
> # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
> 37494
> # cat /proc/37494/status | grep NSpid
> NSpid:	37494	1

Also, I think the current PR could produce the wrong answer, if systemd is indeed running inside the container, and we have:


"/user.slice/user-1000.slice/session-50.scope",    // root_path
"/user.slice/user-1000.slice/session-3.scope",     // cgroup_path


The PR gives /sys/fs/cgroup/memory/user.slice/user-1000.slice/, which specifies the overall memory limit for user-1000. However, the correct answer may be /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-3.scope, which may have a smaller memory limit, and the JVM may end up allocating a larger heap than allowed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From rriggs at openjdk.java.net  Thu May 19 20:36:58 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 May 2022 20:36:58 GMT
Subject: RFR: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character [v9]
In-Reply-To: <gW6MccDl1j5z1UTgET1Ea8MTnZCKcoMKjcG33LkKzTQ=.de8ad983-825f-4090-9c7e-1d369d289488@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
 <gW6MccDl1j5z1UTgET1Ea8MTnZCKcoMKjcG33LkKzTQ=.de8ad983-825f-4090-9c7e-1d369d289488@github.com>
Message-ID: <bF0Npz04Lp0hpiObVPy2fHGzfiQY1SxoN8wiY1nkwSQ=.8dd732dd-9f01-4b60-bcf1-ab175a3e6932@github.com>

On Tue, 17 May 2022 01:19:30 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> On JDK19 with Linux ja_JP.eucjp locale,
>> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
>> It seems this issue happens because of JEP 400.
>> Arguments for ProcessBuilder have same kind of issue.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

Looks fine.
(I don't personally like how {@return looks in the source; but its done now. Usually it is preferred to stick to the style in the file and not mix stylistic changes with functional changes).
Thanks for the updates.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8378

From duke at openjdk.java.net  Thu May 19 20:46:40 2022
From: duke at openjdk.java.net (Srinivas Vamsi Parasa)
Date: Thu, 19 May 2022 20:46:40 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v2]
In-Reply-To: <HZ7Krri1nvZwxHK9gWR38oXbnSBntPl0OiOX8cVbB7w=.aa4a1456-f8e6-4045-afb4-1d1672d1f448@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <HZ7Krri1nvZwxHK9gWR38oXbnSBntPl0OiOX8cVbB7w=.aa4a1456-f8e6-4045-afb4-1d1672d1f448@github.com>
Message-ID: <MZXdI-iuZKuGQkClD9321Nl1cpZC1EATP6-BteYalis=.bc71a7c6-f6d9-4e38-bde3-25416dc6c91f@github.com>

On Wed, 18 May 2022 14:59:49 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
>> 
>> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>>     jne     label
>> 
>> into
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>> 
>> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
>> 
>>         xorl    ecx, ecx
>>         ucomiss xmm0, xmm1
>>         jnp     done
>>         pushf
>>         andq    [rsp], 0xffffff2b
>>         popf
>>     done:
>>         movl    eax, 1
>>         cmovel  eax, ecx
>> 
>> The patch changes this sequence into
>> 
>>     xorl    ecx, ecx
>>     ucomiss xmm0, xmm1
>>     movl    eax, 1
>>     cmovpl  eax, ecx
>>     cmovnel eax, ecx
>> 
>> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
>> 
>> The benchmark results are as follow:
>> 
>>     Before:
>>     Benchmark                      Mode  Cnt     Score     Error  Units
>>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  ns/op
>>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  ns/op
>>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  ns/op
>>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  ns/op
>>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  ns/op
>>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  ns/op
>>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  ns/op
>>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  ns/op
>> 
>>     After:
>>     Benchmark                      Mode  Cnt     Score     Error  Units
>>     FPComparison.equalDouble       avgt    5   594.636 ?   8.922  ns/op
>>     FPComparison.equalFloat        avgt    5   663.849 ?   3.656  ns/op
>>     FPComparison.isFiniteDouble    avgt    5   518.309 ? 107.352  ns/op
>>     FPComparison.isFiniteFloat     avgt    5   515.576 ?  14.669  ns/op
>>     FPComparison.isInfiniteDouble  avgt    5   621.185 ?  11.935  ns/op
>>     FPComparison.isInfiniteFloat   avgt    5   623.566 ?  15.206  ns/op
>>     FPComparison.isNanDouble       avgt    5   400.124 ?   0.762  ns/op
>>     FPComparison.isNanFloat        avgt    5   546.486 ?   1.509  ns/op
>> 
>> Thank you very much.
>
> Quan Anh Mai 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 eight additional commits since the last revision:
> 
>  - incidental ws
>  - add tests
>  - Merge branch 'master' into fpcompare
>  - fix tests
>  - test
>  - improve infinity
>  - remove expensive rules
>  - improve fp comparison

Could you pls show the performance delta with the baseline and after the patch? Otherwise, people reviewing this PR have to manually compute how much improvement is obtained. For example, `FPComparison.isNanFloat` is showing `4.7x` improvement. Kindly fill the delta column for rest of the data points. 

Instead of two separate tables, the suggested table format for each row would be:
`<benchmark> , <baseline throughput> , <this patch throughput>, <performance delta in % or x>`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From rriggs at openjdk.java.net  Thu May 19 20:59:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 May 2022 20:59:01 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <jbBaODyPtTd8-tuH-COiI2ThXfoKUWG-KPHV-il4ohQ=.0fc3bc38-0236-4244-8094-1dab9a2ba505@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From jbhateja at openjdk.java.net  Thu May 19 21:11:41 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 19 May 2022 21:11:41 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v7]
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <Wl-EtWeIkrBxGKkRsHQcBXejOLyB6cHfxn_nwmzlLtI=.8e0f5ae6-ade4-4d41-9b9a-554b458f7db3@github.com>

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms.
 - 8284960: Adding --enable-preview in vectorAPI benchmarks.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Review comments resolution.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Correcting a typo.
 - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9f562ef7...311f3233

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8425/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=06
  Stats: 38049 lines in 228 files changed: 16683 ins; 16923 del; 4443 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425

PR: https://git.openjdk.java.net/jdk/pull/8425

From jbhateja at openjdk.java.net  Thu May 19 21:14:18 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 19 May 2022 21:14:18 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v3]
In-Reply-To: <JOyBytPc5GKq_P9rwPd25FihD9m7AfnXEAjWxsj9GRQ=.29caa4ec-dcb5-4b9e-9e30-dbb1cac6c986@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
 <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
 <Sbf6Rj5Zz8KFJIGpJmdMH9ScVs3CeKgINDk4d8L-nNc=.e259a479-e03f-445a-a641-413fe0183ec8@github.com>
 <rWRoQRmRyI6tQ4SeZo1qC9Pbc201-YytIVrGX3wBJ9E=.e364352d-f6af-48f9-bf86-dc27fa977468@github.com>
 <JOyBytPc5GKq_P9rwPd25FihD9m7AfnXEAjWxsj9GRQ=.29caa4ec-dcb5-4b9e-9e30-dbb1cac6c986@github.com>
Message-ID: <nxDZQrZ3xbFn6AvndQvT0IWivzy7HO9IC8gRnM7DhXM=.dbb4af53-439c-48fe-9ebc-ecb55bca57df@github.com>

On Thu, 19 May 2022 15:33:49 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Do you mean it's important to apply the transformation at the right node (pick the right node as the root) and it is hard to make a decision during GVN?
>
> Yes, that what I meant, but with recently added Node::Flag_is_predicated_using_blend it could be possible to move this transformation ahead into idealization routines of reverse/reverse bytes IR nodes.

Addressed this after internally discussing with Sandhya. Moved the transforms from final graph re-shaping back to vector intrinsic routines.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From psandoz at openjdk.java.net  Thu May 19 21:23:22 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 19 May 2022 21:23:22 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v7]
In-Reply-To: <Wl-EtWeIkrBxGKkRsHQcBXejOLyB6cHfxn_nwmzlLtI=.8e0f5ae6-ade4-4d41-9b9a-554b458f7db3@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <Wl-EtWeIkrBxGKkRsHQcBXejOLyB6cHfxn_nwmzlLtI=.8e0f5ae6-ade4-4d41-9b9a-554b458f7db3@github.com>
Message-ID: <L-Zv6suxvjRBekoyZ-jsPcSI3UIEMfLst11Iu6kkg84=.2764a092-1fc9-4afd-b33a-2b7c811bfdf0@github.com>

On Thu, 19 May 2022 21:11:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms.
>  - 8284960: Adding --enable-preview in vectorAPI benchmarks.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Review comments resolution.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Correcting a typo.
>  - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9f562ef7...311f3233

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 50:

> 48: import java.util.Set;
> 49: 
> 50: import static com.sun.tools.javac.code.Flags.PREVIEW_API;

Suggestion:


Redundant import (sorry i should have checked before i sent you updates to this area)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From aturbanov at openjdk.java.net  Thu May 19 21:23:45 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 19 May 2022 21:23:45 GMT
Subject: RFR: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable [v2]
In-Reply-To: <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
 <k2FZvkdByXSiIzrs2wGQZ1s2xMi9zMWlIklz_XYwQRQ=.fe7a2a51-fa67-4deb-bf89-dad20f61c181@github.com>
Message-ID: <vSSWEeLopB9OfgPnj3bMmrcDoWqUaXU1Vx4Ob-Sr2e4=.00db113f-cfe6-41a7-b227-fbd8bb96819f@github.com>

On Thu, 31 Mar 2022 08:03:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Method `Class.isAssignableFrom` is often used in form of:
>> 
>>     if (clazz.isAssignableFrom(obj.getClass())) {
>> Such condition could be simplified to more shorter and performarnt code
>> 
>>     if (clazz.isInstance(obj)) {
>>     
>> Replacement is equivalent if it's known that `obj != null`.
>> In JDK codebase there are many such places.
>> 
>> I tried to measure performance via JMH
>> 
>>     Class<?> integerClass = Integer.class;
>>     Class<?> numberClass = Number.class;
>> 
>>     Object integerObject = 45666;
>>     Object doubleObject = 8777d;
>> 
>>     @Benchmark
>>     public boolean integerInteger_isInstance() {
>>         return integerClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerInteger_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isInstance() {
>>         return integerClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean integerDouble_isAssignableFrom() {
>>         return integerClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isInstance() {
>>         return numberClass.isInstance(doubleObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberDouble_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(doubleObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isInstance() {
>>         return numberClass.isInstance(integerObject);
>>     }
>> 
>>     @Benchmark
>>     public boolean numberInteger_isAssignableFrom() {
>>         return numberClass.isAssignableFrom(integerObject.getClass());
>>     }
>> 
>>     @Benchmark
>>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>>         bh.consume(numberClass.isInstance(integerObject));
>>         bh.consume(numberClass.isInstance(doubleObject));
>>     }
>> 
>>     @Benchmark
>>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>>     }
>> 
>> `isInstance` is a bit faster than `isAssignableFrom`
>> 
>> Benchmark                              Mode  Cnt  Score   Error  Units
>> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
>> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
>> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
>> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
>> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
>> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
>> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
>> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
>> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
>> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
>   apply suggestion to avoid second Method.invoke call

Thank you for review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From aturbanov at openjdk.java.net  Thu May 19 21:24:20 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 19 May 2022 21:24:20 GMT
Subject: RFR: 8287053: Avoid redundant HashMap.containsKey calls in
 ZoneInfoFile.getZoneInfo0
Message-ID: <LlL9rKAuLvh_eGitin7ESJnZUOePjHhtYyuLuoa2hsU=.34ef6d1f-1dbd-409c-b049-fc783ba17bb5@github.com>

Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`.
It's faster and clearer.

-------------

Commit messages:
 - [PATCH] Avoid redundant HashMap.containsKey calls in ZoneInfoFile

Changes: https://git.openjdk.java.net/jdk/pull/8487/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8487&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287053
  Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8487.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8487/head:pull/8487

PR: https://git.openjdk.java.net/jdk/pull/8487

From aturbanov at openjdk.java.net  Thu May 19 21:46:09 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 19 May 2022 21:46:09 GMT
Subject: Integrated: 8280035: Use Class.isInstance instead of
 Class.isAssignableFrom where applicable
In-Reply-To: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
References: <LHLbTxboRWf8My2OJoSQc968PA_AwS1YZXScvywjzO0=.995ff433-e0b8-450e-af46-1aeef507ae76@github.com>
Message-ID: <m5Mlh_GXpRbgYU6ZFCOd4XxqZaSy9yYVTOz5Mnnr69I=.4c5baad6-401b-41b0-af78-60b6a3e417a8@github.com>

On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Method `Class.isAssignableFrom` is often used in form of:
> 
>     if (clazz.isAssignableFrom(obj.getClass())) {
> Such condition could be simplified to more shorter and performarnt code
> 
>     if (clazz.isInstance(obj)) {
>     
> Replacement is equivalent if it's known that `obj != null`.
> In JDK codebase there are many such places.
> 
> I tried to measure performance via JMH
> 
>     Class<?> integerClass = Integer.class;
>     Class<?> numberClass = Number.class;
> 
>     Object integerObject = 45666;
>     Object doubleObject = 8777d;
> 
>     @Benchmark
>     public boolean integerInteger_isInstance() {
>         return integerClass.isInstance(integerObject);
>     }
> 
>     @Benchmark
>     public boolean integerInteger_isAssignableFrom() {
>         return integerClass.isAssignableFrom(integerObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean integerDouble_isInstance() {
>         return integerClass.isInstance(doubleObject);
>     }
> 
>     @Benchmark
>     public boolean integerDouble_isAssignableFrom() {
>         return integerClass.isAssignableFrom(doubleObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean numberDouble_isInstance() {
>         return numberClass.isInstance(doubleObject);
>     }
> 
>     @Benchmark
>     public boolean numberDouble_isAssignableFrom() {
>         return numberClass.isAssignableFrom(doubleObject.getClass());
>     }
> 
>     @Benchmark
>     public boolean numberInteger_isInstance() {
>         return numberClass.isInstance(integerObject);
>     }
> 
>     @Benchmark
>     public boolean numberInteger_isAssignableFrom() {
>         return numberClass.isAssignableFrom(integerObject.getClass());
>     }
> 
>     @Benchmark
>     public void numberIntegerDouble_isInstance(Blackhole bh) {
>         bh.consume(numberClass.isInstance(integerObject));
>         bh.consume(numberClass.isInstance(doubleObject));
>     }
> 
>     @Benchmark
>     public void integerIntegerDouble_isAssignableFrom(Blackhole bh) {
>         bh.consume(integerClass.isAssignableFrom(integerObject.getClass()));
>         bh.consume(integerClass.isAssignableFrom(doubleObject.getClass()));
>     }
> 
> `isInstance` is a bit faster than `isAssignableFrom`
> 
> Benchmark                              Mode  Cnt  Score   Error  Units
> integerDouble_isAssignableFrom         avgt    5  1,173 ? 0,026  ns/op
> integerDouble_isInstance               avgt    5  0,939 ? 0,038  ns/op
> integerIntegerDouble_isAssignableFrom  avgt    5  2,106 ? 0,068  ns/op
> numberIntegerDouble_isInstance         avgt    5  1,516 ? 0,046  ns/op
> integerInteger_isAssignableFrom        avgt    5  1,175 ? 0,029  ns/op
> integerInteger_isInstance              avgt    5  0,886 ? 0,017  ns/op
> numberDouble_isAssignableFrom          avgt    5  1,172 ? 0,007  ns/op
> numberDouble_isInstance                avgt    5  0,891 ? 0,030  ns/op
> numberInteger_isAssignableFrom         avgt    5  1,169 ? 0,014  ns/op
> numberInteger_isInstance               avgt    5  0,887 ? 0,016  ns/op

This pull request has now been integrated.

Changeset: de74e0e2
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/de74e0e25a195084745891419f0c4a8ad286560c
Stats:     25 lines in 10 files changed: 0 ins; 3 del; 22 mod

8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable

Reviewed-by: prr, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/7061

From asemenyuk at openjdk.java.net  Thu May 19 21:51:28 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 19 May 2022 21:51:28 GMT
Subject: RFR: 8281682: Redundant .ico files in Windows app-image cause
 unnecessary bloat
Message-ID: <i1lsikErMof0IvPkgfxYiOCOaAMuS3P1EOKj21ulDw4=.7d7d5610-0ca7-459c-9eef-5e506de5be23@github.com>

8281682: Redundant .ico files in Windows app-image cause unnecessary bloat

-------------

Commit messages:
 - Trailing whitespace removed
 - Drop unused WinIconVerifierException
 - remove accidentally added space char
 - jtreg descriptions fixed
 - 8281682: Redundant .ico files in Windows app-image cause unnecessary bloat

Changes: https://git.openjdk.java.net/jdk/pull/8794/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8794&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281682
  Stats: 169 lines in 8 files changed: 150 ins; 6 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8794.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8794/head:pull/8794

PR: https://git.openjdk.java.net/jdk/pull/8794

From alexander.matveev at oracle.com  Thu May 19 22:38:19 2022
From: alexander.matveev at oracle.com (Alexander Matveev)
Date: Thu, 19 May 2022 22:38:19 +0000
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <100F2A28-281F-4F19-A07E-846B414FD517@gmail.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <100F2A28-281F-4F19-A07E-846B414FD517@gmail.com>
Message-ID: <54F714D8-A1A0-4D43-AD69-418C0F84993E@oracle.com>

Hi Michael,

I think it will be a problem to implement this for native launchers.
- If we extract native launchers inside installed app bundle it will invalidate signature and most likely will require privileged permissions to write inside app bundle.
- If we extract to some known and accessible location as you suggesting, then how our launchers will figure out which runtime to use? All other runtime files will be inside app bundle.
- If user deletes application, then how we will cleanup extracted files? Most likely it will require uninstall script in known location which user will need to run in order to cleanup extracted files.

Thanks,
Alexander

On May 18, 2022, at 6:44 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On May 11, 2022, at 4:39 PM, Alexander Matveev <almatvee at openjdk.java.net<mailto:almatvee at openjdk.java.net>> wrote:

- It is not possible to support native JDK commands such as "java" inside Mac App Store bundles due to embedded info.plist. Workarounds suggested in JDK-8286122 does not seems to be visible.

I was just thinking about this. If you wanted a workaround to suggest to the user on the original issue. You could jar the native executables, extract them to a known accessible location, and then runtime them.

Having the commands jar?d would get them past the App Store check. Runtime on the client machine I doubt would object to the duplicate bundle id?s on absolute path execution but I haven?t double checked that. Also avoids issues with quarantine xattr?s.
I?ve done something like this a couple times for interfacing an app to other languages.

For example?

if (Files.exists(rscriptCmd)) {
isR = true;
System.out.println("InitialFinance: RScript available");
// Where is the finance data directory?
String data = prefs.get("data","N/A");

if (data.equals("N/A")) {
Application app = Application.getApplication();
Path documents = app.getFolder(DataTypes.DOCUMENTS);
dataLoc = Paths.get(documents.toString(),"finance");
}
else {
dataLoc = Paths.get(data);
}
System.out.println("InitialFinance: data location is " + dataLoc);
Path resourceJar = Paths.get(System.getProperty("app.path"),"resource.jar");
System.out.println("InitialFinance: Checking resources for updates");
extractArchive(resourceJar,dataLoc);
}
else {
System.out.println("InitialFinance: " + rscriptCmd + " for " + initialRscript + " does not exist");
isR = false;
}

// https://stackoverflow.com/questions/1529611/how-to-write-a-java-program-which-can-extract-a-jar-file-and-store-its-data-in-s
    public static void extractArchive(Path archiveFile, Path destPath) throws IOException {
        Files.createDirectories(destPath); // create dest path folder(s)
        try (ZipFile archive = new ZipFile(archiveFile.toFile())) {

         @SuppressWarnings("unchecked")
         Enumeration<ZipEntry> entries = (Enumeration<ZipEntry>) archive.entries();

            // copy or create new or updated
         while (entries.hasMoreElements()) {
         ZipEntry entry = entries.nextElement();

         if (!entry.getName().startsWith("finance/") || !(entry.getName().length() > 8)) {
         continue;
         }
         String fileName = entry.getName().substring(8);
         FileTime archiveTime = entry.getLastModifiedTime();

                Path entryDest = destPath.resolve(fileName);
                //if (Files.isDirectory(entryDest)) continue;
                //Files.createDirectories(entryDest);
         if (!Files.exists(entryDest)) {
         Files.copy(archive.getInputStream(entry), entryDest, StandardCopyOption.REPLACE_EXISTING);
         continue;
         }
                BasicFileAttributes destAttr =
                        Files.readAttributes(entryDest, BasicFileAttributes.class);

                if (archiveTime.compareTo(destAttr.creationTime()) > 0) {
                    Files.copy(archive.getInputStream(entry), entryDest, StandardCopyOption.REPLACE_EXISTING);
                }
            }
        }
        catch (IOException ioex) {
         throw ioex;
        }
    }

boolean debug = Boolean.getBoolean("R.debug");
rtexec(new String[] { RSCRIPT, script.toString() },debug);



From almatvee at openjdk.java.net  Thu May 19 22:45:45 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 19 May 2022 22:45:45 GMT
Subject: RFR: 8281682: Redundant .ico files in Windows app-image cause
 unnecessary bloat
In-Reply-To: <i1lsikErMof0IvPkgfxYiOCOaAMuS3P1EOKj21ulDw4=.7d7d5610-0ca7-459c-9eef-5e506de5be23@github.com>
References: <i1lsikErMof0IvPkgfxYiOCOaAMuS3P1EOKj21ulDw4=.7d7d5610-0ca7-459c-9eef-5e506de5be23@github.com>
Message-ID: <88yGIMoy8uhH1vF6Cmr09vsdrlNR_hFaV_Jy0ETmVh0=.3a00ecbb-e4ec-48a6-9199-fa86f670854b@github.com>

On Thu, 19 May 2022 19:13:12 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8281682: Redundant .ico files in Windows app-image cause unnecessary bloat

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8794

From mik3hall at gmail.com  Thu May 19 23:10:39 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 19 May 2022 18:10:39 -0500
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <54F714D8-A1A0-4D43-AD69-418C0F84993E@oracle.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <100F2A28-281F-4F19-A07E-846B414FD517@gmail.com>
 <54F714D8-A1A0-4D43-AD69-418C0F84993E@oracle.com>
Message-ID: <C8966DBD-8AA4-4378-8760-0FA9723AFB82@gmail.com>



> On May 19, 2022, at 5:38 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Michael,

Alexander

> 
> I think it will be a problem to implement this for native launchers.

Each of the native commands is it?s own app launcher? I didn?t know this. I don?t think it was ever really indicated in the discussion why the commands needed the embedded plist. I think Apple DTS guessed it had something to do with a TCC issue.

> - If we extract native launchers inside installed app bundle it will invalidate signature and most likely will require privileged permissions to write inside app bundle.

I thought maybe jpackage unsigned and resigned the jdk itself. Maybe not. I was talking about simply including a jar in input that ends up in the ?app? directory and the app then has the jar contents extracted from there. No additional write permission?s are required. 

> - If we extract to some known and accessible location as you suggesting, then how our launchers will figure out which runtime to use? All other runtime files will be inside app bundle.

Again this possibly my not understanding what additional requirements there are for the commands to be ?launchers?. I was thinking if the embedded plist was still a problem the developer could possibly use commands from a compatible linux distribution. OS/X and linux are both Unix right? It did occur to me that extracting native commands out of a jar might lose the executable posix permission. I?m not sure if jar has any builtin meta information to retain these permissions or if nio allows you to set executable. I haven?t had to address this. 

> - If user deletes application, then how we will cleanup extracted files? Most likely it will require uninstall script in known location which user will need to run in order to cleanup extracted files.

I haven?t tried to address this yet myself for my application. I?m not sure a lot of OS/X application?s do. But it would probably be up to the app to provide an uninstall of some kind. Some app?s are obviously going to need external data.

> 
> Thanks,
> Alexander
> 

Again I?m suggesting it as a roughed out workaround suggestion for the developer. There might be issues they would need to work out and might even be problems where it won?t work.
I?m not suggesting it as a fix you would try to implement.

Thanks
Mike


From itakiguchi at openjdk.java.net  Thu May 19 23:41:57 2022
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Thu, 19 May 2022 23:41:57 GMT
Subject: Integrated: 8285517: System.getenv() returns unexpected value if
 environment variable has non ASCII character
In-Reply-To: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
References: <a3MVi4Myz9Xf4l2bYBFCFSJFIW2Mio1thDoHimen2oY=.9af3609a-e65a-4330-a6bd-378e26ef408b@github.com>
Message-ID: <PWLuovuQOofncX_NLWzEp-q7_NvJ-eWXow-VDGLRHHY=.3bd00419-d63c-4f3f-9e6d-e447b4476a42@github.com>

On Sun, 24 Apr 2022 09:18:54 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> On JDK19 with Linux ja_JP.eucjp locale,
> System.getenv() returns unexpected value if environment variable has Japanese EUC characters.
> It seems this issue happens because of JEP 400.
> Arguments for ProcessBuilder have same kind of issue.

This pull request has now been integrated.

Changeset: 890771e7
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/890771e708277c5f7ea9460ff7bcc7e4cae87eab
Stats:     264 lines in 5 files changed: 217 ins; 24 del; 23 mod

8285517: System.getenv() returns unexpected value if environment variable has non ASCII character

Reviewed-by: naoto, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8378

From duke at openjdk.java.net  Thu May 19 23:44:12 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 19 May 2022 23:44:12 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v3]
In-Reply-To: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
Message-ID: <OStgY1PdPJqJiSG70ARRKrbtijHMbcvzKVgT-__RE0Q=.4f65f935-1da4-428b-8cbb-4540728138f4@github.com>

> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
> 
> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.

liach 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:

 - Updates suggested by mandy
 - Merge branch 'master' into fix/proxy-single-pass
 - Don't need to complexify module cache
 - 8284942: Proxy building can just iterate superinterfaces once

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8281/files
  - new: https://git.openjdk.java.net/jdk/pull/8281/files/d58bb7e0..502dad82

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=01-02

  Stats: 259862 lines in 4149 files changed: 190963 ins; 46360 del; 22539 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8281/head:pull/8281

PR: https://git.openjdk.java.net/jdk/pull/8281

From psandoz at openjdk.java.net  Thu May 19 23:51:27 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 19 May 2022 23:51:27 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v7]
In-Reply-To: <Wl-EtWeIkrBxGKkRsHQcBXejOLyB6cHfxn_nwmzlLtI=.8e0f5ae6-ade4-4d41-9b9a-554b458f7db3@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <Wl-EtWeIkrBxGKkRsHQcBXejOLyB6cHfxn_nwmzlLtI=.8e0f5ae6-ade4-4d41-9b9a-554b458f7db3@github.com>
Message-ID: <Lm7tWRyHa2Ys8Ni5lf2DITOBmkdKa00RPUbaAFqzI5o=.114cca36-7f4a-4504-abba-6442f39a927f@github.com>

On Thu, 19 May 2022 21:11:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms.
>  - 8284960: Adding --enable-preview in vectorAPI benchmarks.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Review comments resolution.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Correcting a typo.
>  - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9f562ef7...311f3233

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 132:

> 130:      * @return true if {@code s} is participating in the preview of {@code previewSymbol}
> 131:      */
> 132:     public boolean isPreviewParticipating(Symbol s, Symbol previewSymbol) {

Some feedback from a colleague:
Suggestion:

    /**
     * Returns true if {@code s} is deemed to participate in the preview of {@code previewSymbol}, and
     * therefore no warnings or errors will be produced.
     *
     * @param s the symbol depending on the preview symbol
     * @param previewSymbol the preview symbol marked with @Preview
     * @return true if {@code s} is participating in the preview of {@code previewSymbol}
     */
    public boolean participatesInPreview(Symbol s, Symbol previewSymbol) {

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From mchung at openjdk.java.net  Fri May 20 00:13:59 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 May 2022 00:13:59 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v3]
In-Reply-To: <OStgY1PdPJqJiSG70ARRKrbtijHMbcvzKVgT-__RE0Q=.4f65f935-1da4-428b-8cbb-4540728138f4@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <OStgY1PdPJqJiSG70ARRKrbtijHMbcvzKVgT-__RE0Q=.4f65f935-1da4-428b-8cbb-4540728138f4@github.com>
Message-ID: <YVQ7GMQ03C5cZYKAEGSHD5mgsHdlA2bvsUnf_BZh50o=.e1ff3297-199e-46a3-944b-3d921868d8db@github.com>

On Thu, 19 May 2022 23:44:12 GMT, liach <duke at openjdk.java.net> wrote:

>> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
>> 
>> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.
>
> liach 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:
> 
>  - Updates suggested by mandy
>  - Merge branch 'master' into fix/proxy-single-pass
>  - Don't need to complexify module cache
>  - 8284942: Proxy building can just iterate superinterfaces once

Looks good with a couple comments.

src/java.base/share/classes/java/lang/reflect/Proxy.java line 509:

> 507:                 if (!m.isNamed())
> 508:                     throw new InternalError("unnamed module: " + m);
> 509:             } else if (proxyPkg.isEmpty() && m.isNamed()) {

With the refactoring, it may be easier to understand to make this check for both public and non-public access (i.e. drop the `else`) for clarity - a named module can't have unnamed package.

src/java.base/share/classes/java/lang/reflect/Proxy.java line 534:

> 532:              * Generate the specified proxy class.
> 533:              */
> 534:             accessFlags |= Modifier.FINAL;

It can be inlined in the call to `generateProxyClass`:


            byte[] proxyClassFile = ProxyGenerator.generateProxyClass(loader, proxyName, interfaces, accessFlags | Modifier.FINAL);

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From mik3hall at gmail.com  Fri May 20 00:14:26 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 19 May 2022 19:14:26 -0500
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <C8966DBD-8AA4-4378-8760-0FA9723AFB82@gmail.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <100F2A28-281F-4F19-A07E-846B414FD517@gmail.com>
 <54F714D8-A1A0-4D43-AD69-418C0F84993E@oracle.com>
 <C8966DBD-8AA4-4378-8760-0FA9723AFB82@gmail.com>
Message-ID: <0BCD0261-7AE1-4E1A-ADD4-27C981F63C47@gmail.com>



> 
> Alexander
> 
>> 
>> I think it will be a problem to implement this for native launchers.
> 

Basically you are telling the developer in https://bugs.openjdk.java.net/browse/JDK-8286122 <https://bugs.openjdk.java.net/browse/JDK-8286122> that it isn?t currently possible for their application to get into the Mac App Store as is.
I was thinking you could possibly in the comments mention the possibility the developer could provide these in an archive themselves that they manually manage as a workaround. 
Leave them with a possible path forward to achieve this.
I have successfully done this for something similar if not identical.


From duke at openjdk.java.net  Fri May 20 01:33:43 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 20 May 2022 01:33:43 GMT
Subject: Withdrawn: 8282178: Replace simple iterations of Map.entrySet with
 Map.forEach calls
In-Reply-To: <ZrjfKueNVJLdOKF1C-gYh85l4pKBrg47-OF_alKrHng=.9ecae4cb-226b-48ef-a5d8-a3db25d86ac4@github.com>
References: <ZrjfKueNVJLdOKF1C-gYh85l4pKBrg47-OF_alKrHng=.9ecae4cb-226b-48ef-a5d8-a3db25d86ac4@github.com>
Message-ID: <PG5-ggLXBAbxVEj_K6-f3zzoxUZD2uDjxcSC0t0STlM=.c58338b2-ab88-4a53-a8d5-f72181224d2d@github.com>

On Wed, 23 Feb 2022 22:33:42 GMT, liach <duke at openjdk.java.net> wrote:

> Replaces simple `for (Map.Entry<K, V> entry : map.entrySet())` with `map.forEach((k, v) ->)` calls. This change is better for thread-safety and reduces allocation for some map implementations.
> 
> A more in-depth description of benefits is available at https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086201.html and at the JBS issue itself.
> 
> A [jmh comparison](https://jmh.morethan.io/?sources=https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/base-results.json,https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/head-results.json) on the performance of the existing `HashMapBench` shows that the performance of `putAll` for `HashMap` has not significantly changed.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7601

From duke at openjdk.java.net  Fri May 20 02:25:32 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 20 May 2022 02:25:32 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v4]
In-Reply-To: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
Message-ID: <RtOpX4OMD3kepUTXjP_WkfsaG--PafeQiZArJR48dyE=.96fca2e4-e46a-45b8-af9b-c72bd233d873@github.com>

> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
> 
> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.

liach has updated the pull request incrementally with one additional commit since the last revision:

  Update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8281/files
  - new: https://git.openjdk.java.net/jdk/pull/8281/files/502dad82..26bde80b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=02-03

  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8281/head:pull/8281

PR: https://git.openjdk.java.net/jdk/pull/8281

From duke at openjdk.java.net  Fri May 20 02:25:33 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 20 May 2022 02:25:33 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v3]
In-Reply-To: <YVQ7GMQ03C5cZYKAEGSHD5mgsHdlA2bvsUnf_BZh50o=.e1ff3297-199e-46a3-944b-3d921868d8db@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <OStgY1PdPJqJiSG70ARRKrbtijHMbcvzKVgT-__RE0Q=.4f65f935-1da4-428b-8cbb-4540728138f4@github.com>
 <YVQ7GMQ03C5cZYKAEGSHD5mgsHdlA2bvsUnf_BZh50o=.e1ff3297-199e-46a3-944b-3d921868d8db@github.com>
Message-ID: <zkAH0lkLad2anCCCZe4ckQwQBs_8Rw2-jmIxjJmHEU8=.b65042a9-9b47-46b3-8c70-88b2085b6f26@github.com>

On Fri, 20 May 2022 00:08:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> a named module can't have unnamed package

Since this is mandated by the Java Language Specification 7.4.2, I am tempted to change the thrown exception to `InternalError`, but I cannot find any restriction in the JVM Specification that prevents declaring a package-private superinterface in the unnamed package of a named module. If we can find a reference in the JVM Specification, I'm more than glad to refer to that in a comment and throw `InternalError` instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From mik3hall at gmail.com  Fri May 20 02:38:15 2022
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 19 May 2022 21:38:15 -0500
Subject: RFR: 8286122: [macos]: App bundle cannot upload to Mac App Store
 due to info.plist embedded in java exe
In-Reply-To: <0BCD0261-7AE1-4E1A-ADD4-27C981F63C47@gmail.com>
References: <c1D8QAJQRHdR4maw4oJsYfzEkWrCMxq0KrLZqp9QOLY=.58fe2568-ae46-47f2-bae7-147de3d6f05f@github.com>
 <100F2A28-281F-4F19-A07E-846B414FD517@gmail.com>
 <54F714D8-A1A0-4D43-AD69-418C0F84993E@oracle.com>
 <C8966DBD-8AA4-4378-8760-0FA9723AFB82@gmail.com>
 <0BCD0261-7AE1-4E1A-ADD4-27C981F63C47@gmail.com>
Message-ID: <919C849C-A133-49D8-9655-8DE1CF5D09BA@gmail.com>



> On May 19, 2022, at 7:14 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> 
>> Alexander
>> 
>>> 
>>> I think it will be a problem to implement this for native launchers.
>> 
> 
> Basically you are telling the developer in https://bugs.openjdk.java.net/browse/JDK-8286122 <https://bugs.openjdk.java.net/browse/JDK-8286122> that it isn?t currently possible for their application to get into the Mac App Store as is.
> I was thinking you could possibly in the comments mention the possibility the developer could provide these in an archive themselves that they manually manage as a workaround. 
> Leave them with a possible path forward to achieve this.
> I have successfully done this for something similar if not identical.
> 

I think it can work for java commands as well. You have to set them executable after extraction and point to the embedded jdk lib directory

DYLD_LIBRARY_PATH=JavaCommand.app/Contents/runtime/Contents/Home/lib JavaCommand.app/Contents/MacOS/JavaCommand 
java version "18" 2022-03-22
Java(TM) SE Runtime Environment (build 18+36-2087)
Java HotSpot(TM) 64-Bit Server VM (build 18+36-2087, mixed mode)

I can provide the full JavaCommand source code and jpackage invocation if of interest. But yes, it works.

From?

String v = rtexec(new String[] { Paths.get(dataLoc,"java").toString(),"-version" });
System.out.println(v);

You?d have to figure out how to provide the environment variable on the runtime invocation. That I didn?t verify, but it doesn?t seem impossible.
I added that after getting?

JavaCommand.app/Contents/MacOS/JavaCommand
dyld[5725]: Library not loaded: @rpath/libjli.dylib
  Referenced from: /Users/mjh/testLoc/java
  Reason: tried: '/libjli.dylib' (no such file), '/Users/mjh/JavaCommand.app/Contents/app/libjli.dylib' (no such file), '/Users/mjh/testLoc/./libjli.dylib' (no such file), '/Users/mjh/testLoc/../lib/libjli.dylib' (no such file), '/Users/mjh/testLoc/./libjli.dylib' (no such file), '/Users/mjh/testLoc/../lib/libjli.dylib' (no such file), '/usr/lib/libjli.dylib' (no such file)


From duke at openjdk.java.net  Fri May 20 04:02:33 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 20 May 2022 04:02:33 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg `Class.forName`
 to avoid unnecessary class initialization
Message-ID: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>

Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of `Class.forName(String)`. `make test TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new `LazyInitializationTest` failing the eager initialization check on the baseline and passing with this patch.

On a side note, this might reduce the number of methods that can be encoded in a proxy due to code attribute size restrictions; we probably would address that in another issue, as we never mandated a count of methods that the proxy must be able to implement.

Mandy, would you mind review this?

-------------

Commit messages:
 - whitespace
 - Copyright year
 - typo
 - 8285401: Proxy class initializer should use 3-arg `Class.forName` to avoid unnecessary class initialization
 - Test for eager initialization

Changes: https://git.openjdk.java.net/jdk/pull/8800/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8800&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285401
  Stats: 78 lines in 2 files changed: 74 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8800.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8800/head:pull/8800

PR: https://git.openjdk.java.net/jdk/pull/8800

From duke at openjdk.java.net  Fri May 20 04:06:19 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 20 May 2022 04:06:19 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v2]
In-Reply-To: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
Message-ID: <MJMhC45M4BWk_PVNtT0XsoNZ29-5Fkn2FUxCAEq0Zo4=.746103db-215a-42b7-a9c2-92070227e985@github.com>

> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of `Class.forName(String)`. `make test TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new `LazyInitializationTest` failing the eager initialization check on the baseline and passing with this patch.
> 
> On a side note, this might reduce the number of methods that can be encoded in a proxy due to code attribute size restrictions; we probably would address that in another issue, as we never mandated a count of methods that the proxy must be able to implement.
> 
> Mandy, would you mind review this?

liach has updated the pull request incrementally with one additional commit since the last revision:

  remove unused field

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8800/files
  - new: https://git.openjdk.java.net/jdk/pull/8800/files/c1b522d5..64a70479

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8800&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8800&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8800.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8800/head:pull/8800

PR: https://git.openjdk.java.net/jdk/pull/8800

From duke at openjdk.java.net  Fri May 20 05:02:08 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 20 May 2022 05:02:08 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo
Message-ID: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>

Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)

-------------

Commit messages:
 - 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo

Changes: https://git.openjdk.java.net/jdk/pull/8801/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8801&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287064
  Stats: 79 lines in 1 file changed: 14 ins; 41 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8801.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8801/head:pull/8801

PR: https://git.openjdk.java.net/jdk/pull/8801

From aturbanov at openjdk.java.net  Fri May 20 08:09:45 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 20 May 2022 08:09:45 GMT
Subject: RFR: 8286858: Remove dead code in sun.reflect.misc.MethodUtil
In-Reply-To: <BOv7D8d_G7_7rAB85Cg_mS8tHjazW-cmvFdJU9xN7ic=.4cd10886-4dc5-4bf2-94ef-2094cc6ac836@github.com>
References: <yNqsZAqSuObV3UY7t5A6Y97uP2qHF5wxmseBBCa4VQw=.f26b2841-fe20-4ba5-b491-dc98f7e75cd2@github.com>
 <BOv7D8d_G7_7rAB85Cg_mS8tHjazW-cmvFdJU9xN7ic=.4cd10886-4dc5-4bf2-94ef-2094cc6ac836@github.com>
Message-ID: <-imJxk5EhCGAxh5RI2LZGtYBLdmvBI9PD6QRIYIYTcw=.1de17e31-a3fb-40f9-9d8f-1030c86b4836@github.com>

On Wed, 18 May 2022 02:03:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>Do you know why there are test failures (they look unrelated)?

All failed tests seems Loom-integration related. They fail only x86. Seems they are fixed in master under [JDK-8286476 ](https://bugs.openjdk.java.net/browse/JDK-8286476)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8715

From redestad at openjdk.java.net  Fri May 20 08:19:03 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 20 May 2022 08:19:03 GMT
Subject: RFR: 8287053: Avoid redundant HashMap.containsKey calls in
 ZoneInfoFile.getZoneInfo0
In-Reply-To: <LlL9rKAuLvh_eGitin7ESJnZUOePjHhtYyuLuoa2hsU=.34ef6d1f-1dbd-409c-b049-fc783ba17bb5@github.com>
References: <LlL9rKAuLvh_eGitin7ESJnZUOePjHhtYyuLuoa2hsU=.34ef6d1f-1dbd-409c-b049-fc783ba17bb5@github.com>
Message-ID: <rYoGeyp-vfA-QwZuLhCv2CEqJdrfwSMa1ckzMEXAk9Q=.a29f9e5d-6412-4127-8d16-e702f80577a2@github.com>

On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`.
> It's faster and clearer.

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8487

From redestad at openjdk.java.net  Fri May 20 08:20:46 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 20 May 2022 08:20:46 GMT
Subject: Integrated: 8287013: StringConcatFactory: remove short and byte
 mixers/prependers
In-Reply-To: <Mi149SNDBYdQof7inBBjDau2ukKhguKSfOZwM1lsLkU=.541b9da5-1f3b-41ca-a3a3-415a18b0acbf@github.com>
References: <Mi149SNDBYdQof7inBBjDau2ukKhguKSfOZwM1lsLkU=.541b9da5-1f3b-41ca-a3a3-415a18b0acbf@github.com>
Message-ID: <kfCSY5wUddN92b5tv8X_sB9PZSlP-eZnAS11ipIOU6o=.ca4a4bd7-927c-4a57-8057-1e07b025440b@github.com>

On Thu, 19 May 2022 10:47:23 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The current short and byte mixers and prependers simply delegate to the int variants. At the LambdaForm level the values has already been implicitly cast to int, so removing this indirection and directly adapting to call the int-based variants is possible.
> 
> This is a cleanup with minimal effect on bootstrap overhead and peak performance, since all the LF logic only deals with basic types (where byte and short and other subword primitives has been widened to ints anyhow).

This pull request has now been integrated.

Changeset: d5d19f52
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d5d19f52ceb1430104b12a42c78489f42477a9b0
Stats:     87 lines in 2 files changed: 12 ins; 74 del; 1 mod

8287013: StringConcatFactory: remove short and byte mixers/prependers

Reviewed-by: jlaskey

-------------

PR: https://git.openjdk.java.net/jdk/pull/8786

From mkartashev at openjdk.java.net  Fri May 20 08:42:19 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Fri, 20 May 2022 08:42:19 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance()
Message-ID: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>

Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. 

It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map.

-------------

Commit messages:
 - 8287073: NPE from CgroupV2Subsystem.getInstance()

Changes: https://git.openjdk.java.net/jdk/pull/8803/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8803&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287073
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8803/head:pull/8803

PR: https://git.openjdk.java.net/jdk/pull/8803

From ihse at openjdk.java.net  Fri May 20 08:42:44 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 20 May 2022 08:42:44 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <RmHbfRXO30BBvfEUmUW7R2l6YV8gOypiJVRi-E1Z40E=.2275399d-8168-4fd2-8f39-2a6be94db1db@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Build changes look good. Thanks for the cleanup!

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From aturbanov at openjdk.java.net  Fri May 20 09:13:45 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 20 May 2022 09:13:45 GMT
Subject: Integrated: 8286858: Remove dead code in sun.reflect.misc.MethodUtil
In-Reply-To: <yNqsZAqSuObV3UY7t5A6Y97uP2qHF5wxmseBBCa4VQw=.f26b2841-fe20-4ba5-b491-dc98f7e75cd2@github.com>
References: <yNqsZAqSuObV3UY7t5A6Y97uP2qHF5wxmseBBCa4VQw=.f26b2841-fe20-4ba5-b491-dc98f7e75cd2@github.com>
Message-ID: <G_EyjRZudT2VtDyz4mmcoJBktFvX5IoO7Na8fFqbMeg=.bee6a878-c0ab-4bec-b7b7-b2fd545cd680@github.com>

On Sun, 15 May 2022 12:47:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> They are unused and leftover since JDK 7.  It's good to remove them.

This pull request has now been integrated.

Changeset: 4587337e
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4587337e956ed6f1a59e9d980a09ab9f784fbde0
Stats:     179 lines in 1 file changed: 4 ins; 170 del; 5 mod

8286858: Remove dead code in sun.reflect.misc.MethodUtil

Reviewed-by: mchung, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/8715

From jbhateja at openjdk.java.net  Fri May 20 09:51:24 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 20 May 2022 09:51:24 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v8]
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8284960: Integrating incremental patches.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8425/files
  - new: https://git.openjdk.java.net/jdk/pull/8425/files/311f3233..17a0e38c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=06-07

  Stats: 32 lines in 7 files changed: 0 ins; 26 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425

PR: https://git.openjdk.java.net/jdk/pull/8425

From jbhateja at openjdk.java.net  Fri May 20 09:51:27 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 20 May 2022 09:51:27 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v7]
In-Reply-To: <L-Zv6suxvjRBekoyZ-jsPcSI3UIEMfLst11Iu6kkg84=.2764a092-1fc9-4afd-b33a-2b7c811bfdf0@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <Wl-EtWeIkrBxGKkRsHQcBXejOLyB6cHfxn_nwmzlLtI=.8e0f5ae6-ade4-4d41-9b9a-554b458f7db3@github.com>
 <L-Zv6suxvjRBekoyZ-jsPcSI3UIEMfLst11Iu6kkg84=.2764a092-1fc9-4afd-b33a-2b7c811bfdf0@github.com>
Message-ID: <fAIRmChafqqG76JfkG6xAC-DK0leV-tG-K8txLrnsIc=.f64700d9-7bf2-4535-bf2c-49ad1e9d6f21@github.com>

On Thu, 19 May 2022 21:19:49 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms.
>>  - 8284960: Adding --enable-preview in vectorAPI benchmarks.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - 8284960: Review comments resolution.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - 8284960: Correcting a typo.
>>  - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9f562ef7...311f3233
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 50:
> 
>> 48: import java.util.Set;
>> 49: 
>> 50: import static com.sun.tools.javac.code.Flags.PREVIEW_API;
> 
> Suggestion:
> 
> 
> Redundant import (sorry i should have checked before i sent you updates to this area)

Merged

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 132:
> 
>> 130:      * @return true if {@code s} is participating in the preview of {@code previewSymbol}
>> 131:      */
>> 132:     public boolean isPreviewParticipating(Symbol s, Symbol previewSymbol) {
> 
> Some feedback from a colleague:
> Suggestion:
> 
>     /**
>      * Returns true if {@code s} is deemed to participate in the preview of {@code previewSymbol}, and
>      * therefore no warnings or errors will be produced.
>      *
>      * @param s the symbol depending on the preview symbol
>      * @param previewSymbol the preview symbol marked with @Preview
>      * @return true if {@code s} is participating in the preview of {@code previewSymbol}
>      */
>     public boolean participatesInPreview(Symbol s, Symbol previewSymbol) {

Merged.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From mcimadamore at openjdk.java.net  Fri May 20 10:37:20 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 20 May 2022 10:37:20 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v8]
In-Reply-To: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
Message-ID: <xfsjAc7umPYKoAc2Gv_MerZmsJflSZjUascvBdlOo9g=.83903741-3293-4c7b-8431-65377528d776@github.com>

On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284960: Integrating incremental patches.

Javac changes look good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8425

From mcimadamore at openjdk.java.net  Fri May 20 10:42:54 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 20 May 2022 10:42:54 GMT
Subject: RFR: 8286825: Linker naming cleanup
In-Reply-To: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
References: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
Message-ID: <9jnTsMW4B2W18WOMSTF3-GzAUXng1DumM3X3RiYKZiU=.d4824b31-20e3-42ad-9143-2984db5f22fe@github.com>

On Wed, 18 May 2022 16:54:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch is a batch naming cleanup for the foreign linker implementation.
> 
> The naming changes are as follows:
> 
>   - ProgrammableInvoker -> DowncallLinker
>   - ProgrammableUpcallHandler -> UpcallLinker
>   - 'native invoker' -> 'downcall stub'
>   - 'optimzed entry blob' -> 'upcall stub'
>   - OptimizedEntryBlob -> UpcallStub
>   - optimized_entry_frame -> upcall_stub_frame
> 
> Then renaming of some hotspot files:
> 
>   - universalNativeInvoker* -> downcallLinker*
>   - universalUpcallHandler* -> upcallLinker*
>   - foreign_globals* -> foreignGlobals* (to match existing convention)
>   
> Method, field, and other variable names are also adjusted accordingly.

Looks good - I spotted a potential issue in the risc-v port

src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 30:

> 28: #include "utilities/debug.hpp"
> 29: 
> 30: address UpcallLinker::generate_optimized_upcall_stub(jobject receiver, Method* entry,

Hasn't "generated_optimized_upcall_stub" changed too?

src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 38:

> 36:   ShouldNotCallThis();
> 37:   return nullptr;
> 38: }

Missing newline (this was here before)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8777

From jvernee at openjdk.java.net  Fri May 20 10:42:55 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 20 May 2022 10:42:55 GMT
Subject: RFR: 8286825: Linker naming cleanup
In-Reply-To: <9jnTsMW4B2W18WOMSTF3-GzAUXng1DumM3X3RiYKZiU=.d4824b31-20e3-42ad-9143-2984db5f22fe@github.com>
References: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
 <9jnTsMW4B2W18WOMSTF3-GzAUXng1DumM3X3RiYKZiU=.d4824b31-20e3-42ad-9143-2984db5f22fe@github.com>
Message-ID: <iLwzXWvwOXnp8gHTuoEnJRhpExSlhAUnrPXCpO5pmz0=.c6a8150f-a2aa-4751-9535-36fce3c78c7f@github.com>

On Fri, 20 May 2022 10:36:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch is a batch naming cleanup for the foreign linker implementation.
>> 
>> The naming changes are as follows:
>> 
>>   - ProgrammableInvoker -> DowncallLinker
>>   - ProgrammableUpcallHandler -> UpcallLinker
>>   - 'native invoker' -> 'downcall stub'
>>   - 'optimzed entry blob' -> 'upcall stub'
>>   - OptimizedEntryBlob -> UpcallStub
>>   - optimized_entry_frame -> upcall_stub_frame
>> 
>> Then renaming of some hotspot files:
>> 
>>   - universalNativeInvoker* -> downcallLinker*
>>   - universalUpcallHandler* -> upcallLinker*
>>   - foreign_globals* -> foreignGlobals* (to match existing convention)
>>   
>> Method, field, and other variable names are also adjusted accordingly.
>
> src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 30:
> 
>> 28: #include "utilities/debug.hpp"
>> 29: 
>> 30: address UpcallLinker::generate_optimized_upcall_stub(jobject receiver, Method* entry,
> 
> Hasn't "generated_optimized_upcall_stub" changed too?

Right, I missed that one. Good catch!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8777

From jvernee at openjdk.java.net  Fri May 20 10:57:44 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 20 May 2022 10:57:44 GMT
Subject: RFR: 8286825: Linker naming cleanup [v2]
In-Reply-To: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
References: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
Message-ID: <Q9b-ESFS_MVQK-fOPmvNf_LuNM5bGs9hW6vzL-dwXc0=.0352e21f-3cde-414c-9dbe-f15c11c1e01e@github.com>

> This patch is a batch naming cleanup for the foreign linker implementation.
> 
> The naming changes are as follows:
> 
>   - ProgrammableInvoker -> DowncallLinker
>   - ProgrammableUpcallHandler -> UpcallLinker
>   - 'native invoker' -> 'downcall stub'
>   - 'optimzed entry blob' -> 'upcall stub'
>   - OptimizedEntryBlob -> UpcallStub
>   - optimized_entry_frame -> upcall_stub_frame
> 
> Then renaming of some hotspot files:
> 
>   - universalNativeInvoker* -> downcallLinker*
>   - universalUpcallHandler* -> upcallLinker*
>   - foreign_globals* -> foreignGlobals* (to match existing convention)
>   
> Method, field, and other variable names are also adjusted accordingly.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Comments + cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8777/files
  - new: https://git.openjdk.java.net/jdk/pull/8777/files/7b0e3a88..b362a822

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8777&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8777&range=00-01

  Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8777.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8777/head:pull/8777

PR: https://git.openjdk.java.net/jdk/pull/8777

From jvernee at openjdk.java.net  Fri May 20 10:57:44 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 20 May 2022 10:57:44 GMT
Subject: RFR: 8286825: Linker naming cleanup
In-Reply-To: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
References: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
Message-ID: <0wbzj-LtCrnhvjjNAE9Qgqn1LI0EwmYL-x3T7jlKVVU=.7f373475-6368-4056-abe6-a1f161314324@github.com>

On Wed, 18 May 2022 16:54:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch is a batch naming cleanup for the foreign linker implementation.
> 
> The naming changes are as follows:
> 
>   - ProgrammableInvoker -> DowncallLinker
>   - ProgrammableUpcallHandler -> UpcallLinker
>   - 'native invoker' -> 'downcall stub'
>   - 'optimzed entry blob' -> 'upcall stub'
>   - OptimizedEntryBlob -> UpcallStub
>   - optimized_entry_frame -> upcall_stub_frame
> 
> Then renaming of some hotspot files:
> 
>   - universalNativeInvoker* -> downcallLinker*
>   - universalUpcallHandler* -> upcallLinker*
>   - foreign_globals* -> foreignGlobals* (to match existing convention)
>   
> Method, field, and other variable names are also adjusted accordingly.

Addressed now. I also noticed some names in strings that weren't updated yet. Updated those as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8777

From jlahoda at openjdk.java.net  Fri May 20 11:13:39 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 20 May 2022 11:13:39 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v8]
In-Reply-To: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
Message-ID: <l95hyWxzRvIR3LohL0Brjc--X4byuGPFUlhNakpRlQY=.71bf7a26-cce6-4023-b828-06d4954dad13@github.com>

On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284960: Integrating incremental patches.

The javac changes look OK to me.

-------------

Marked as reviewed by jlahoda (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8425

From mcimadamore at openjdk.java.net  Fri May 20 11:09:55 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 20 May 2022 11:09:55 GMT
Subject: RFR: 8286825: Linker naming cleanup [v2]
In-Reply-To: <Q9b-ESFS_MVQK-fOPmvNf_LuNM5bGs9hW6vzL-dwXc0=.0352e21f-3cde-414c-9dbe-f15c11c1e01e@github.com>
References: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
 <Q9b-ESFS_MVQK-fOPmvNf_LuNM5bGs9hW6vzL-dwXc0=.0352e21f-3cde-414c-9dbe-f15c11c1e01e@github.com>
Message-ID: <N8SrVPcygg0lHLt5VuV6WohuMa_zaPEvZhWst6d3QmE=.04e0a5d9-aff2-471b-950b-cf5de953df6e@github.com>

On Fri, 20 May 2022 10:57:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch is a batch naming cleanup for the foreign linker implementation.
>> 
>> The naming changes are as follows:
>> 
>>   - ProgrammableInvoker -> DowncallLinker
>>   - ProgrammableUpcallHandler -> UpcallLinker
>>   - 'native invoker' -> 'downcall stub'
>>   - 'optimzed entry blob' -> 'upcall stub'
>>   - OptimizedEntryBlob -> UpcallStub
>>   - optimized_entry_frame -> upcall_stub_frame
>> 
>> Then renaming of some hotspot files:
>> 
>>   - universalNativeInvoker* -> downcallLinker*
>>   - universalUpcallHandler* -> upcallLinker*
>>   - foreign_globals* -> foreignGlobals* (to match existing convention)
>>   
>> Method, field, and other variable names are also adjusted accordingly.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments + cleanup

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8777

From duke at openjdk.java.net  Fri May 20 11:55:50 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 20 May 2022 11:55:50 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v2]
In-Reply-To: <MJMhC45M4BWk_PVNtT0XsoNZ29-5Fkn2FUxCAEq0Zo4=.746103db-215a-42b7-a9c2-92070227e985@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
 <MJMhC45M4BWk_PVNtT0XsoNZ29-5Fkn2FUxCAEq0Zo4=.746103db-215a-42b7-a9c2-92070227e985@github.com>
Message-ID: <5Q70s9K9gLahO46U1mL2Mk7QhRrEkuL-8L_Q6Z8X330=.8175631e-bb82-4084-9a5a-a4094f193996@github.com>

On Fri, 20 May 2022 04:06:19 GMT, liach <duke at openjdk.java.net> wrote:

>> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of `Class.forName(String)`. `make test TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new `LazyInitializationTest` failing the eager initialization check on the baseline and passing with this patch.
>> 
>> On a side note, this might reduce the number of methods that can be encoded in a proxy due to code attribute size restrictions; we probably would address that in another issue, as we never mandated a count of methods that the proxy must be able to implement.
>> 
>> Mandy, would you mind review this?
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused field

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 608:

> 606:         mv.visitMethodInsn(INVOKEVIRTUAL, JL_CLASS,
> 607:                 "getClassLoader", "()" + LJL_CLASSLOADER, false);
> 608:         mv.visitVarInsn(ASTORE, 0);

Shouldn?t this?go?before `mv.visitLabel(L_startBlock)`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8800

From naoto at openjdk.java.net  Fri May 20 15:52:50 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 20 May 2022 15:52:50 GMT
Subject: RFR: 8287053: Avoid redundant HashMap.containsKey calls in
 ZoneInfoFile.getZoneInfo0
In-Reply-To: <LlL9rKAuLvh_eGitin7ESJnZUOePjHhtYyuLuoa2hsU=.34ef6d1f-1dbd-409c-b049-fc783ba17bb5@github.com>
References: <LlL9rKAuLvh_eGitin7ESJnZUOePjHhtYyuLuoa2hsU=.34ef6d1f-1dbd-409c-b049-fc783ba17bb5@github.com>
Message-ID: <Xv1OHIl9W8z3nMWRn1MbDnES4PMvxcW10VBeCpswKH4=.014942ba-8c4e-41f5-8074-ba732b83538d@github.com>

On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`.
> It's faster and clearer.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8487

From rriggs at openjdk.java.net  Fri May 20 15:52:51 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 20 May 2022 15:52:51 GMT
Subject: RFR: 8287053: Avoid redundant HashMap.containsKey calls in
 ZoneInfoFile.getZoneInfo0
In-Reply-To: <LlL9rKAuLvh_eGitin7ESJnZUOePjHhtYyuLuoa2hsU=.34ef6d1f-1dbd-409c-b049-fc783ba17bb5@github.com>
References: <LlL9rKAuLvh_eGitin7ESJnZUOePjHhtYyuLuoa2hsU=.34ef6d1f-1dbd-409c-b049-fc783ba17bb5@github.com>
Message-ID: <Uj3GKDt5NAIhz1Qul4EvBxsMMCGKvjNL01FpV7gbYyQ=.f2f70bfa-9a1f-4e8a-9b35-ed4a8b3c1791@github.com>

On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`.
> It's faster and clearer.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8487

From duke at openjdk.java.net  Fri May 20 16:18:01 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Fri, 20 May 2022 16:18:01 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v7]
In-Reply-To: <eIV170ZddGZdrvsmFhGKOgTV0z2flhzUFpg1Q2V6nvg=.de4a7f39-829e-4cf0-9213-d1cb8cfd0c24@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <htYdycTglPNEcws_0LXa76d1hZ3sLDajoQWCOLBn09I=.09d59e6c-1f85-4725-a0a9-52bc97410834@github.com>
 <LzlvvHF_2DFM-tMDycm8c0PRlW80lvI8D4T00vx2za0=.2bb8be64-00a6-464e-abd5-77e6a8ffae0f@github.com>
 <9qHMVzzj99xltKBUztmZicgH6IJrUqk_yHD410_5Iqo=.5a70b46a-d145-4e3d-a33f-932a64a4489b@github.com>
 <J11y9Ci5g5NmlLWcWm1qItJ0tVN4sil6bFaa_KF4Dek=.972b61cf-8ff4-440d-826b-ed92049914ca@github.com>
 <eIV170ZddGZdrvsmFhGKOgTV0z2flhzUFpg1Q2V6nvg=.de4a7f39-829e-4cf0-9213-d1cb8cfd0c24@github.com>
Message-ID: <cg0lHVbjoKIZh07FWiTIwszx79bFT3DWEplO2f1BsTI=.85b4d6c4-d88e-4ed1-bf34-624fa79c198b@github.com>

On Wed, 20 Apr 2022 16:36:16 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>>> no, we use other way, but yes for we take care of thread safety.
>> 
>> Fair enough.
>> 
>>> Don't think it necessary... I think making it cannot touched by other object (with security manager on) is enough.
>> 
>> I was thinking more for heapdumps due to extending the life of the skip buffer in this patch.  At least we don't have to waste more cycles.
>> 
>> Oh I forgot last time but, it looks like MIN_SKIP_BUFFER_SIZE is not used.  Unless I'm missing something I assume that is a bug.
>
> @jmehrens comments about not making it static added.

> @XenoAmess This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From jlahoda at openjdk.java.net  Fri May 20 18:20:58 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 20 May 2022 18:20:58 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
Message-ID: <O1fTVr3kJlmiqfPjj74P29-2u9nnr6paGQFlVD4sl7w=.f049b649-fe9f-401c-b641-17b66d1a7edc@github.com>

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected LimitedImage test description

FWIW, if adding this dependency would be seen unacceptable, we could try to tweak jlink to at least produce a warning when building an image with jdk.compiler but without jdk.zipfs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8747

From duke at openjdk.java.net  Fri May 20 18:22:47 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 20 May 2022 18:22:47 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v3]
In-Reply-To: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
Message-ID: <Uh30nZyDeqt2ARI5Y-FXoBKabCJxYebhgaimCdixxOo=.87c7c3c5-6310-45f2-b9b8-b390052c1f9e@github.com>

> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of `Class.forName(String)`. `make test TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new `LazyInitializationTest` failing the eager initialization check on the baseline and passing with this patch.
> 
> On a side note, this might reduce the number of methods that can be encoded in a proxy due to code attribute size restrictions; we probably would address that in another issue, as we never mandated a count of methods that the proxy must be able to implement.
> 
> Mandy, would you mind review this?

liach has updated the pull request incrementally with one additional commit since the last revision:

  Move the try catch block as it doesn't throw checked exceptions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8800/files
  - new: https://git.openjdk.java.net/jdk/pull/8800/files/64a70479..82f8eeb9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8800&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8800&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8800.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8800/head:pull/8800

PR: https://git.openjdk.java.net/jdk/pull/8800

From duke at openjdk.java.net  Fri May 20 18:22:48 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 20 May 2022 18:22:48 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v2]
In-Reply-To: <5Q70s9K9gLahO46U1mL2Mk7QhRrEkuL-8L_Q6Z8X330=.8175631e-bb82-4084-9a5a-a4094f193996@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
 <MJMhC45M4BWk_PVNtT0XsoNZ29-5Fkn2FUxCAEq0Zo4=.746103db-215a-42b7-a9c2-92070227e985@github.com>
 <5Q70s9K9gLahO46U1mL2Mk7QhRrEkuL-8L_Q6Z8X330=.8175631e-bb82-4084-9a5a-a4094f193996@github.com>
Message-ID: <RK_USS9_WyqPRnnXLz_jyua6uP6iv1UWfHcch8ovrJ4=.6cfa7cb3-3ab4-4a1f-854b-e42b718ef61a@github.com>

On Fri, 20 May 2022 11:51:09 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> liach has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused field
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 608:
> 
>> 606:         mv.visitMethodInsn(INVOKEVIRTUAL, JL_CLASS,
>> 607:                 "getClassLoader", "()" + LJL_CLASSLOADER, false);
>> 608:         mv.visitVarInsn(ASTORE, 0);
> 
> Shouldn?t this?go?before `mv.visitLabel(L_startBlock)`?

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8800

From rriggs at openjdk.java.net  Fri May 20 18:49:04 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 20 May 2022 18:49:04 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]
In-Reply-To: <h9BjimboAkIuIUbUrWAnFB-w0L6u98DeDWnSItdldnk=.a708fe0f-537a-4d75-93e2-d2d16257d047@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <h9BjimboAkIuIUbUrWAnFB-w0L6u98DeDWnSItdldnk=.a708fe0f-537a-4d75-93e2-d2d16257d047@github.com>
Message-ID: <RZfEIi44785RYY6Rb0FPOVlaWe-E4OAzcWLgnSsV1Og=.ec930661-54b6-4f42-813c-337a356b70a8@github.com>

On Tue, 17 May 2022 23:40:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato 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 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8279185
>  - Addressing review comments
>  - Revert to use the default method
>  - Removed unnecessary package names
>  - Modified class desc of `IsoFields`
>  - abstract class -> top level interface
>  - interface -> abstract class
>  - Removed the method
>  - Changed to use a type to determine ISO based or not
>  - Renamed the new method
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/2761b08b...3f69909f

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7683

From joehw at openjdk.java.net  Fri May 20 19:32:57 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 20 May 2022 19:32:57 GMT
Subject: RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]
In-Reply-To: <h9BjimboAkIuIUbUrWAnFB-w0L6u98DeDWnSItdldnk=.a708fe0f-537a-4d75-93e2-d2d16257d047@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
 <h9BjimboAkIuIUbUrWAnFB-w0L6u98DeDWnSItdldnk=.a708fe0f-537a-4d75-93e2-d2d16257d047@github.com>
Message-ID: <eVGrzMnuGG48QTy9JwhaND04cXvpfwl1dF8peterMhU=.8c310bad-a585-47e8-83f5-3ce8e8bf50dc@github.com>

On Tue, 17 May 2022 23:40:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.
>
> Naoto Sato 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 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8279185
>  - Addressing review comments
>  - Revert to use the default method
>  - Removed unnecessary package names
>  - Modified class desc of `IsoFields`
>  - abstract class -> top level interface
>  - interface -> abstract class
>  - Removed the method
>  - Changed to use a type to determine ISO based or not
>  - Renamed the new method
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/3b1d6d84...3f69909f

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7683

From rriggs at openjdk.java.net  Fri May 20 19:57:40 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 20 May 2022 19:57:40 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v3]
In-Reply-To: <Uh30nZyDeqt2ARI5Y-FXoBKabCJxYebhgaimCdixxOo=.87c7c3c5-6310-45f2-b9b8-b390052c1f9e@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
 <Uh30nZyDeqt2ARI5Y-FXoBKabCJxYebhgaimCdixxOo=.87c7c3c5-6310-45f2-b9b8-b390052c1f9e@github.com>
Message-ID: <JKEi-hPmGef595yW5uaxUu-J3xXBc0aNGMqTDVJlYkI=.f149fcbc-5964-49b3-8a01-29a692cdc6b7@github.com>

On Fri, 20 May 2022 18:22:47 GMT, liach <duke at openjdk.java.net> wrote:

>> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of `Class.forName(String)`. `make test TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new `LazyInitializationTest` failing the eager initialization check on the baseline and passing with this patch.
>> 
>> On a side note, this might reduce the number of methods that can be encoded in a proxy due to code attribute size restrictions; we probably would address that in another issue, as we never mandated a count of methods that the proxy must be able to implement.
>> 
>> Mandy, would you mind review this?
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the try catch block as it doesn't throw checked exceptions

Looks fine.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8800

From rriggs at openjdk.java.net  Fri May 20 20:05:45 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 20 May 2022 20:05:45 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo
In-Reply-To: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
Message-ID: <FpAQfBPbrTJgkGSBhrDCpJi0r87DV15dWElskM5DUEU=.c50cdad6-da89-479b-8c3d-2d9cb0da3c34@github.com>

On Fri, 20 May 2022 04:55:37 GMT, liach <duke at openjdk.java.net> wrote:

> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 932:

> 930:      */
> 931:     private static final class PrimitiveTypeInfo {
> 932:         private static final PrimitiveTypeInfo BYTE = new PrimitiveTypeInfo(byte.class, 0);

Can this be `private enum PrimitiveTypeInfo...` or perhaps a record class?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From rriggs at openjdk.java.net  Fri May 20 21:18:53 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 20 May 2022 21:18:53 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v12]
In-Reply-To: <klI6NyXEyt_6yk0qlFaL0rsgczPFy5VNqsq5t0SlAmM=.947091f7-c3f0-49c6-b241-f2c1f2b9ff98@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <klI6NyXEyt_6yk0qlFaL0rsgczPFy5VNqsq5t0SlAmM=.947091f7-c3f0-49c6-b241-f2c1f2b9ff98@github.com>
Message-ID: <QTDlYzqFPN4YaLgUFr7zY6yHyxBjCl0xHAqtJxduMf0=.5164328a-3833-4f5d-b54c-cdbe6ce7a04a@github.com>

On Wed, 20 Apr 2022 16:52:31 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add documents

src/java.base/share/classes/java/io/InputStream.java line 72:

> 70:      *
> 71:      * @param size minimum length that the skip byte array must have.
> 72:      *             notice that this param input MUST be equal or less than {@link #MAX_SKIP_BUFFER_SIZE MAX_SKIP_BUFFER_SIZE}.

The "MUST be equal" reads like something will go wrong if that condition isn't satisfied.
This method does not care about the size, except in potentially resizing if the requested size is larger.

The "notice..." statement is making a statement about code in the caller, and so doesn't belong here.

src/java.base/share/classes/java/io/InputStream.java line 75:

> 73:      * @return the byte array.
> 74:      */
> 75:     private byte[] skipBufferReference(int size) {

The method name would match the return value better if named `skipBuffer(size)`.

src/java.base/share/classes/java/io/InputStream.java line 78:

> 76:         SoftReference<byte[]> ref = this.skipBufferReference;
> 77:         byte[] buffer;
> 78:         if (ref == null || (buffer = ref.get()) == null || buffer.length < size) {

A comment here or in the method javadoc to the effect that a new buffer is allocated unless the existing buffer is large enough might head off doubt that buffer is always non-null at the return.  As would inverting the if:

   if (ref != null && (buffer = ref.get()) != null && buffer.length >= size) {
      return buffer;
   }
   // allocate new or larger buffer
   buffer = new byte[size];
   this.skipBufferReference = new SoftReference<>(buffer);
   return buffer;

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Fri May 20 21:23:02 2022
From: duke at openjdk.java.net (iaroslavski)
Date: Fri, 20 May 2022 21:23:02 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <0d9ibGxiPSy-z1StNpU81FyxWM6bBNrAAj1x-AZlAtE=.f7a6271b-4339-4c1c-9e48-24b96d2813f9@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
 <0d9ibGxiPSy-z1StNpU81FyxWM6bBNrAAj1x-AZlAtE=.f7a6271b-4339-4c1c-9e48-24b96d2813f9@github.com>
Message-ID: <zxQ38y-f7jyeUFNmaqGXXe-Zg9_7cSbtF13pEDxhPJM=.cbfea067-3876-49a4-89b1-e8ece774a9f0@github.com>

On Sun, 15 May 2022 14:17:41 GMT, Piotr Tarsa <duke at openjdk.java.net> wrote:

>> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>>   
>>   * Improved mixed insertion sort
>>   * Optimized insertion sort
>>   * Improved merging sort
>>   * Optimized soring tests
>
> i think it would make much more sense to have the extra buffer size limit in bytes, not in elements. for single-threaded sorting the limit should be low, e.g. 1/64 of the heap, not 1/8 (in case of sorting e.g. longs as each long is 8 byte long). multi-threaded sorting could be more aggressive when it comes to resource usage as it's less likely to be used in resource constrained environment.

@tarsa  Hi Piotr,
 
Thank you for your interest to sorting and your point to allocation of buffers in sorting.
 
Let?s I share my thoughts.
 
The number of elements of any array is not more than ~2 billion
(max positive int value) and therefore the size (in bytes) of
int array is not more than ~2 GB * 4 = ~8 GB.
 
We need additional buffer for int, long, float and double types only.
 
We will have 2 constants which limit the number of int/float and
long/double elements in array, like this:
 
    private static final int MAX_BUFFER_LENGTH_1 =              // for int/float
            (int) Math.min(Runtime.getRuntime().maxMemory() >> 10, Integer.MAX_VALUE);
 
    private static final int MAX_BUFFER_LENGTH_2 =             // for long/double
            (int) Math.min(Runtime.getRuntime().maxMemory() >> 11, Integer.MAX_VALUE);
 
See, that the max number of elements for long/double is in 2 times less than for int/float,
because long/double occupies 2 times more bytes.
 
I take factors 10 and 11 as example, it may be other values, but the first is less than the second by 1.
 
Why do we need to use Math.min(?, Integer.MAX_VALUE)? We must do it in this case:
if  Runtime.getRuntime().maxMemory() >> 11 is larger than max int (for example, we have power server),
casting to int will produce negative value. So, limit by 2 Gb max is required.
 
And the method tryAllocate will look like this:
 
private static Object tryAllocate(Object a, int length) {
    try {
        if (a instanceof int[]) {
            return length > MAX_BUFFER_LENGTH_1 ? null : new int[length];
        }
        if (a instanceof long[]) {
            return length > MAX_BUFFER_LENGTH_2 ? null : new long[length];
        }
        if (a instanceof float[]) {
            return length > MAX_BUFFER_LENGTH_1 ? null : new float[length];
        }
        if (a instanceof double[]) {
            return length > MAX_BUFFER_LENGTH_2 ? null : new double[length];
        }
        throw new IllegalArgumentException("Unknown array: " + a.getClass().getName());
    } catch (OutOfMemoryError e) {
        return null;
    }
}
 
What do you think, what value of shift is the best, 6, 7, 8, 9, 10, 11, 12 etc.?
Runtime.getRuntime().maxMemory() >> 10??
 
Do you have actual scenarios? Actual requirements? Your feedback are welcome!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From sviswanathan at openjdk.java.net  Fri May 20 22:01:48 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 20 May 2022 22:01:48 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
In-Reply-To: <JWs3_k2RjekJyce9EByCxFvuJTQbpvu19A0ay4xB6P0=.1f9f7079-092f-43e4-9ee4-7e8b5fadb3c5@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <JWs3_k2RjekJyce9EByCxFvuJTQbpvu19A0ay4xB6P0=.1f9f7079-092f-43e4-9ee4-7e8b5fadb3c5@github.com>
Message-ID: <iWfQlnqCmWm7aEwCy3Abt55GlowEWPbls-u0ajK28x4=.84c2a8b1-6303-49a3-a485-596d1c14b360@github.com>

On Wed, 18 May 2022 14:59:33 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
>> 
>> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>>     jne     label
>> 
>> into
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>> 
>> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
>> 
>>         xorl    ecx, ecx
>>         ucomiss xmm0, xmm1
>>         jnp     done
>>         pushf
>>         andq    [rsp], 0xffffff2b
>>         popf
>>     done:
>>         movl    eax, 1
>>         cmovel  eax, ecx
>> 
>> The patch changes this sequence into
>> 
>>     xorl    ecx, ecx
>>     ucomiss xmm0, xmm1
>>     movl    eax, 1
>>     cmovpl  eax, ecx
>>     cmovnel eax, ecx
>> 
>> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
>> 
>> The benchmark results are as follow:
>> 
>>     Before:
>>     Benchmark                      Mode  Cnt     Score     Error  Units
>>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  ns/op
>>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  ns/op
>>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  ns/op
>>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  ns/op
>>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  ns/op
>>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  ns/op
>>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  ns/op
>>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  ns/op
>> 
>>     After:
>>     Benchmark                      Mode  Cnt     Score     Error  Units
>>     FPComparison.equalDouble       avgt    5   594.636 ?   8.922  ns/op
>>     FPComparison.equalFloat        avgt    5   663.849 ?   3.656  ns/op
>>     FPComparison.isFiniteDouble    avgt    5   518.309 ? 107.352  ns/op
>>     FPComparison.isFiniteFloat     avgt    5   515.576 ?  14.669  ns/op
>>     FPComparison.isInfiniteDouble  avgt    5   621.185 ?  11.935  ns/op
>>     FPComparison.isInfiniteFloat   avgt    5   623.566 ?  15.206  ns/op
>>     FPComparison.isNanDouble       avgt    5   400.124 ?   0.762  ns/op
>>     FPComparison.isNanFloat        avgt    5   546.486 ?   1.509  ns/op
>> 
>> Thank you very much.
>
> I have reverted the changes to `java.lang.Float` and `java.lang.Double` to not interfere with the intrinsic PR. More tests are added to cover all cases regarding floating-point comparison of compiled code.
> 
> The rules for fp comparison that output the result to `rFlagRegsU` are expensive and should be avoided. As a result, I removed the shortcut rules with memory or constant operands to reduce the number of match rules. Only the basic rules are kept.
> 
> Thanks.

@merykitty Very nice work! The patch looks good to me.

@merykitty Very nice work! The patch looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From duke at openjdk.java.net  Fri May 20 22:18:42 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 20 May 2022 22:18:42 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v2]
In-Reply-To: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
Message-ID: <wzjh1NqTjoYU3FN8Vu2vlofpf_9gL-T9rCs0cQDPLUM=.d29d7d63-2aeb-4f06-b365-499c8b9bfceb@github.com>

> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)

liach has updated the pull request incrementally with one additional commit since the last revision:

  Convert PrimitiveTypeInfo to an enum

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8801/files
  - new: https://git.openjdk.java.net/jdk/pull/8801/files/16f3de8f..be9987bb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8801&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8801&range=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8801.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8801/head:pull/8801

PR: https://git.openjdk.java.net/jdk/pull/8801

From duke at openjdk.java.net  Fri May 20 22:18:42 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 20 May 2022 22:18:42 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v2]
In-Reply-To: <FpAQfBPbrTJgkGSBhrDCpJi0r87DV15dWElskM5DUEU=.c50cdad6-da89-479b-8c3d-2d9cb0da3c34@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <FpAQfBPbrTJgkGSBhrDCpJi0r87DV15dWElskM5DUEU=.c50cdad6-da89-479b-8c3d-2d9cb0da3c34@github.com>
Message-ID: <ntim7j-UNW8uvjJzP_NfANIqdMeyAGdMN_Q9rbeBzdg=.6161fbab-fce1-4693-8072-61d2b3546c7f@github.com>

On Fri, 20 May 2022 20:02:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> liach has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Convert PrimitiveTypeInfo to an enum
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 932:
> 
>> 930:      */
>> 931:     private static final class PrimitiveTypeInfo {
>> 932:         private static final PrimitiveTypeInfo BYTE = new PrimitiveTypeInfo(byte.class, 0);
> 
> Can this be `private enum PrimitiveTypeInfo...` or perhaps a record class?

Thanks. I've converted it into an enum following the suit of `sun.invoke.util.Wrapper`. I think an enum fits better here as we don't need the canonical constructor and object methods of a record.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From sviswanathan at openjdk.java.net  Fri May 20 22:26:55 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 20 May 2022 22:26:55 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v2]
In-Reply-To: <6hRgLEWJfB8OHOYNJReUaMac469hvDuemoURK-aMy4Y=.963b7561-33e0-4069-8d89-8b447d4e0f0f@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <KdpuTVQMeytKodsxscUf6bY-Rb9ZX1mh-JlqxGz3yhc=.ad30bd97-86fe-4ae8-80ff-277eacce88d9@github.com>
 <6hRgLEWJfB8OHOYNJReUaMac469hvDuemoURK-aMy4Y=.963b7561-33e0-4069-8d89-8b447d4e0f0f@github.com>
Message-ID: <4YL6D_2LfQ55wX12ygOKNUCqZo_okfJr0vUcumw5RBk=.6ddd5d8f-9c58-40d6-b6d8-43a65ec57828@github.com>

On Wed, 4 May 2022 23:16:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_64.ad line 6998:
>> 
>>> 6996:   ins_encode %{
>>> 6997:     __ cmovl(Assembler::parity, $dst$$Register, $src$$Register);
>>> 6998:     __ cmovl(Assembler::notEqual, $dst$$Register, $src$$Register);
>> 
>> Should this be `equal`?
>
> I see that you swapped `src, dst` in `match()` but `format` is sill incorrect and the code is confusing.

I agree with @vnkozlov that this needs explanation. Could you please add comments here with IR and example code generated for both the eq case and ne case? You have some explanation in the PR description but not in the code. The description needs to be in the code as well for maintenance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From lmesnik at openjdk.java.net  Fri May 20 22:34:12 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 20 May 2022 22:34:12 GMT
Subject: RFR: 8287103:
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp
Message-ID: <hrjEydmZwHHDMaA9FVahsF0hMIZ-9VBZnklbkyweQR4=.65f58722-52b5-40e8-bcd4-8bcb10a09a29@github.com>

Sync improved in test

-------------

Commit messages:
 - 8287103: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp

Changes: https://git.openjdk.java.net/jdk/pull/8821/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8821&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287103
  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8821.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8821/head:pull/8821

PR: https://git.openjdk.java.net/jdk/pull/8821

From kvn at openjdk.java.net  Fri May 20 22:52:47 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 20 May 2022 22:52:47 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v2]
In-Reply-To: <4YL6D_2LfQ55wX12ygOKNUCqZo_okfJr0vUcumw5RBk=.6ddd5d8f-9c58-40d6-b6d8-43a65ec57828@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <KdpuTVQMeytKodsxscUf6bY-Rb9ZX1mh-JlqxGz3yhc=.ad30bd97-86fe-4ae8-80ff-277eacce88d9@github.com>
 <6hRgLEWJfB8OHOYNJReUaMac469hvDuemoURK-aMy4Y=.963b7561-33e0-4069-8d89-8b447d4e0f0f@github.com>
 <4YL6D_2LfQ55wX12ygOKNUCqZo_okfJr0vUcumw5RBk=.6ddd5d8f-9c58-40d6-b6d8-43a65ec57828@github.com>
Message-ID: <BBJW7-WDvKmnyMsXIMOxW4fiBdqElFRA8LQGYoiQuF8=.eaeb51d0-467b-45e1-ad7a-8378aec2d478@github.com>

On Fri, 20 May 2022 22:22:43 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> I see that you swapped `src, dst` in `match()` but `format` is sill incorrect and the code is confusing.
>
> I agree with @vnkozlov that this needs explanation. Could you please add comments here with IR and example code generated for both the eq case and ne case? You have some explanation in the PR description but not in the code. The description needs to be in the code as well for maintenance.

Right, I missed that. Then you can use `expand %{` to avoid duplication (keep format).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From bchristi at openjdk.java.net  Fri May 20 23:27:41 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 20 May 2022 23:27:41 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v4]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <vhOcQtSMZF4j8tXvkuLWY3WMTSqg4qSnw1N8-R9maxk=.b3799f63-b9f7-402b-8cf6-5c952b4c983d@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  Fix merge

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8311/files
  - new: https://git.openjdk.java.net/jdk/pull/8311/files/9d19775b..6398e5e5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

PR: https://git.openjdk.java.net/jdk/pull/8311

From bchristi at openjdk.java.net  Fri May 20 23:42:48 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 20 May 2022 23:42:48 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v5]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <01Q5I78--t5wDy_7hABFuwO6aNfeJxcOyyqq1elyjBk=.e8408ac0-b3f9-48df-b356-c5124d7a2521@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  Fix the merge fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8311/files
  - new: https://git.openjdk.java.net/jdk/pull/8311/files/6398e5e5..9ffaa788

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

PR: https://git.openjdk.java.net/jdk/pull/8311

From bchristi at openjdk.java.net  Fri May 20 23:57:28 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 20 May 2022 23:57:28 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v6]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <S6UKzNW6BAx-Qw4pyKHqHEXZFGcqZUB1xNp9d0wLwfs=.fce91cad-ec0f-4fe4-b33f-be4866b03c18@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  NOW it builds

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8311/files
  - new: https://git.openjdk.java.net/jdk/pull/8311/files/9ffaa788..a48a56cc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

PR: https://git.openjdk.java.net/jdk/pull/8311

From jpai at openjdk.java.net  Sat May 21 02:24:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 21 May 2022 02:24:40 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
Message-ID: <fg6ldLSMxzqXQS89VUmjFy-hfR_sbyp0XzidZz0xWUM=.e13ab158-02a0-4f16-aeac-0c400286a826@github.com>

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected LimitedImage test description

Thank you for changing the description of the test. That part now looks fine to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8747

From duke at openjdk.java.net  Sat May 21 04:07:41 2022
From: duke at openjdk.java.net (liach)
Date: Sat, 21 May 2022 04:07:41 GMT
Subject: RFR: 8284640: CollectorImpl class could be a record class
In-Reply-To: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
References: <TVb1c7RWBl7Cy8g6BURMdjYYCqX1AR_dsmsyqDCHv5M=.18429d49-c9cc-436c-a1b4-fe72813dc346@github.com>
Message-ID: <DXl_i4N20kgNayXXOTICVSoX835R0hiG11EZFeMp1vo=.89f36144-8b68-444b-a032-1f37daecb2b3@github.com>

On Mon, 11 Apr 2022 13:08:43 GMT, altrisi <duke at openjdk.java.net> wrote:

> Changes the definition of `CollectorImpl` to be a record.

@stuart-marks Mind review this simple cleanup?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8179

From duke at openjdk.java.net  Sat May 21 10:31:25 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 21 May 2022 10:31:25 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v3]
In-Reply-To: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
Message-ID: <v6oWG6skDA-bprsjHiUj65tq2JDbme68QCVr_kdTBKk=.f6b4845f-d91a-4a57-a9f2-ab05cbaa7acc@github.com>

> Hi,
> 
> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
> 
> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
> 
>     ucomiss xmm0, xmm0
>     jp      label
>     jne     label
> 
> into
> 
>     ucomiss xmm0, xmm0
>     jp      label
> 
> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
> 
>         xorl    ecx, ecx
>         ucomiss xmm0, xmm1
>         jnp     done
>         pushf
>         andq    [rsp], 0xffffff2b
>         popf
>     done:
>         movl    eax, 1
>         cmovel  eax, ecx
> 
> The patch changes this sequence into
> 
>     xorl    ecx, ecx
>     ucomiss xmm0, xmm1
>     movl    eax, 1
>     cmovpl  eax, ecx
>     cmovnel eax, ecx
> 
> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
> 
> The benchmark results are as follow:
> 
>                                                      Before              After
>     Benchmark                      Mode  Cnt     Score     Error    Score     Error   Unit   Ratio
>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  594.636 ?   8.922  ns/op    4.84
>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  663.849 ?   3.656  ns/op    4.61
>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  518.309 ? 107.352  ns/op    0.92
>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  515.576 ?  14.669  ns/op    0.98
>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  621.185 ?  11.935  ns/op    1.98
>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  623.566 ?  15.206  ns/op    1.98
>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  400.124 ?   0.762  ns/op    5.64
>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  546.486 ?   1.509  ns/op    4.70
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8525/files
  - new: https://git.openjdk.java.net/jdk/pull/8525/files/ba93dcf2..7fcfe4a3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8525&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8525&range=01-02

  Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8525.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8525/head:pull/8525

PR: https://git.openjdk.java.net/jdk/pull/8525

From duke at openjdk.java.net  Sat May 21 10:46:48 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 21 May 2022 10:46:48 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v3]
In-Reply-To: <aDeexKQXmUKFtVEoRE3yA0H9j1crX92ZGyzEryIzjdA=.48fc5efc-f783-42cc-9cc9-3e0db66aeeda@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <uHIVqB_EGvG41QVcPnw4OJML7-QZTq-kfdWZXe9G8ak=.d2cdb4da-7034-4b86-b0ad-f0da674ceb51@github.com>
 <aDeexKQXmUKFtVEoRE3yA0H9j1crX92ZGyzEryIzjdA=.48fc5efc-f783-42cc-9cc9-3e0db66aeeda@github.com>
Message-ID: <CbT-L4b5RE9j0jOZUcHAzNbwAOMjnijkknPL8BtY3b4=.766dba73-2bfa-4262-adb5-dab7b7b857fb@github.com>

On Wed, 4 May 2022 23:27:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> The changes to `Float` and `Double` look good. I don't think we need additional tests, see test/jdk/java/lang/Math/IeeeRecommendedTests.java.
>> 
>> At first i thought we no longer need PR #8459 but it seems both PRs are complimentary, albeit PR #8459 has more modest performance gains for the intrinsics.
>
>> The changes to `Float` and `Double` look good. I don't think we need additional tests, see test/jdk/java/lang/Math/IeeeRecommendedTests.java.
> 
> Thank you, Paul for pointing the test. It means we need to run tier4 (which runs these tests with -Xcomp) to make sure methods are compiled by C2.

@vnkozlov  I have added comments to describe the changes in `cmpOpUCF` and the reasons behind the `cmov_regUCF2_eq` match rules. Using `expand` broke the build with `Syntax Error: :For expand in cmovI_regUCF2_eq to work, parameter declaration order in cmovI_regUCF2_ne must follow matchrule`.

@sviswa7  (x != y) ? a : b can be calculated using pseudocode as follow:

    res = (!ZF || PF) ? a : b
        = !ZF ? a : (PF ? a : b)

which can be calculated using

    cmovp  rb, ra // rb1 = PF ? ra : rb
    cmovne rb, ra // rb2 = !ZF ? ra : rb1 = !ZF ? ra : (PF ? ra : rb)

Furthermore, since `(x == y) == !(x != y)`, we have `((x == y) ? a : b) == ((x != y) ? b : a)`, which explains the implementation of `cmov_regUCF2_eq`.

@vamsi-parasa Thanks a lot for your suggestion, I have modified the PR description as you say.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From ysuenaga at openjdk.java.net  Sat May 21 13:11:45 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 21 May 2022 13:11:45 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v7]
In-Reply-To: <F7pDEuGXdRxaZ1L8KgQWJ7UIW5z7cEhXcF8ZOSPpwXo=.5a8df23a-e126-4e51-b2a8-db45e3e4424a@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <F7pDEuGXdRxaZ1L8KgQWJ7UIW5z7cEhXcF8ZOSPpwXo=.5a8df23a-e126-4e51-b2a8-db45e3e4424a@github.com>
Message-ID: <ZpAbjCEYlSl49cA5B1UmvcopZia_C1eqRdzCW-kLbBY=.54d9c516-df27-4c26-93fa-1f6ed695d089@github.com>

On Tue, 17 May 2022 13:32:42 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes for memnode.cpp and type.cpp

In case of stringop-overflow errors (bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp) noted that offset of `Array<T>::_data` might be  [-2147483648, -1].

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From kvn at openjdk.java.net  Sat May 21 15:33:41 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 21 May 2022 15:33:41 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v3]
In-Reply-To: <v6oWG6skDA-bprsjHiUj65tq2JDbme68QCVr_kdTBKk=.f6b4845f-d91a-4a57-a9f2-ab05cbaa7acc@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <v6oWG6skDA-bprsjHiUj65tq2JDbme68QCVr_kdTBKk=.f6b4845f-d91a-4a57-a9f2-ab05cbaa7acc@github.com>
Message-ID: <yOdnjW1WJESDYtXu0Ss7TdEJVTVxBaPuBT7ZS6jBHvY=.48889e67-1f5f-4506-ad3c-117892777918@github.com>

On Sat, 21 May 2022 10:31:25 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
>> 
>> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>>     jne     label
>> 
>> into
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>> 
>> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
>> 
>>         xorl    ecx, ecx
>>         ucomiss xmm0, xmm1
>>         jnp     done
>>         pushf
>>         andq    [rsp], 0xffffff2b
>>         popf
>>     done:
>>         movl    eax, 1
>>         cmovel  eax, ecx
>> 
>> The patch changes this sequence into
>> 
>>     xorl    ecx, ecx
>>     ucomiss xmm0, xmm1
>>     movl    eax, 1
>>     cmovpl  eax, ecx
>>     cmovnel eax, ecx
>> 
>> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
>> 
>> The benchmark results are as follow:
>> 
>>                                                      Before              After
>>     Benchmark                      Mode  Cnt     Score     Error    Score     Error   Unit   Ratio
>>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  594.636 ?   8.922  ns/op    4.84
>>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  663.849 ?   3.656  ns/op    4.61
>>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  518.309 ? 107.352  ns/op    0.92
>>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  515.576 ?  14.669  ns/op    0.98
>>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  621.185 ?  11.935  ns/op    1.98
>>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  623.566 ?  15.206  ns/op    1.98
>>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  400.124 ?   0.762  ns/op    5.64
>>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  546.486 ?   1.509  ns/op    4.70
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments

Thank you for trying my suggestion and new comments. Approved.

I started our testing. Please, wait results.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8525

From duke at openjdk.java.net  Sat May 21 18:01:44 2022
From: duke at openjdk.java.net (Piotr Tarsa)
Date: Sat, 21 May 2022 18:01:44 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <Iv0UnrvQSMIWVYfLg2YCovQfPJ3gMWYO6lhJBf3f0po=.8438f93c-34ee-4b7f-aff9-3bd3b9f68ecf@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

hi Vladimir,

the main reason i raise the issue with catching out-of-memory-error is that it's done very rarely in production code and also it's rather unpredictable when multiple things are going on (e.g. one thread can allocate a lot of memory, but other threads receive `oome`).

i've searched through /src/ in openjdk/jdk repository for `oome` (i.e. this one) and found that most times the `oome` is caught is in `java.desktop` module (probably this means the `oome` was related to native memory or other resources external to jvm), so i've narrowed search to `java.base`: https://github.com/search?q=outofmemoryerror+repo%3Aopenjdk%2Fjdk+path%3A%2Fsrc%2Fjava.base%2F+language%3AJava&type=Code&ref=advsearch&l=Java and found just 2 cases of catching `oome` without always rethrowing it:
-  https://github.com/openjdk/jdk/blob/d8b0b32f9f4049aa678809aa068978e3a4e29457/src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java#L1304 (but this rethrows if it internally fails with `oome` for a second time)
- https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java#L1171

overall, it seems that swallowing `oome` (i.e. in this case: catching and not rethrowing) is definitely not a readily used approach.

> We need additional buffer for int, long, float and double types only.
> 
> We will have 2 constants which limit the number of int/float and
long/double elements in array, like this:
> (...)
> See, that the max number of elements for long/double is in 2 times less than for int/float,
because long/double occupies 2 times more bytes.

sounds good

> Why do we need to use Math.min(?, Integer.MAX_VALUE)? (...) So, limit by 2 Gb max is required.

yep, understood

> What do you think, what value of shift is the best, 6, 7, 8, 9, 10, 11, 12 etc.?
> Runtime.getRuntime().maxMemory() >> 10??
>
> Do you have actual scenarios? Actual requirements? Your feedback are welcome!

keeping the extra buffer size below 1% of max memory should be safe enough. currently the code is:

    private static final int MAX_BUFFER_LENGTH =
            (int) Math.min(Runtime.getRuntime().maxMemory() >> 6, 256L << 20);
    // ...
    private static Object tryAllocate(Object a, int length) {
        if (length > MAX_BUFFER_LENGTH) {
            return null;
        }
        try {
            if (a instanceof int[]) {
                return new int[length];
            }
            if (a instanceof long[]) {
                return new long[length];
            }
    ...

which means that in the worst case `sizeof(long) * (max memory >> 6) == 12.5% of heap size limit` would be used which is a lot when someone runs java code in memory constrained environment and that is rather common nowadays (microservices, containers, etc).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From kvn at openjdk.java.net  Sat May 21 19:20:50 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 21 May 2022 19:20:50 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v3]
In-Reply-To: <yOdnjW1WJESDYtXu0Ss7TdEJVTVxBaPuBT7ZS6jBHvY=.48889e67-1f5f-4506-ad3c-117892777918@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <v6oWG6skDA-bprsjHiUj65tq2JDbme68QCVr_kdTBKk=.f6b4845f-d91a-4a57-a9f2-ab05cbaa7acc@github.com>
 <yOdnjW1WJESDYtXu0Ss7TdEJVTVxBaPuBT7ZS6jBHvY=.48889e67-1f5f-4506-ad3c-117892777918@github.com>
Message-ID: <boyhXN8SJr8DcMhGJ3YmmsGwZ_KwXzW3SRFyOTIDEFE=.be04b81c-9b4d-4999-a3a2-0f87057f6902@github.com>

On Sat, 21 May 2022 15:30:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I started our testing. Please, wait results.

Testing passed clean.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From forax at univ-mlv.fr  Sat May 21 22:54:07 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 22 May 2022 00:54:07 +0200 (CEST)
Subject: <T> Stream.fromForEach(Consumer<Consumer<T>>)
Message-ID: <1144676012.11391840.1653173645995.JavaMail.zimbra@u-pem.fr>

Hi all,
a stream is kind of push iterator so it can be created from any object that has a method like forEach(Consumer),
but sadly there is no static method to create a Stream from a Consumer of Consumer so people usually miss that creating a Stream from events pushed to a consumer is easy.

By example, let say i've a very simple parser like this, it calls the listener/callback for each tokens 

  record Parser(String text) {
    void parse(Consumer<? super String> listener) {
      for(var token: text.split(" ")) {
         listener.accept(token);
      }
    }
  } 

Using the method Stream.fromForEach, we can create a Stream from the sequence of tokens that are pushed through the listener
  var parser = new Parser("1 2");
  var stream = Stream.fromForEach(parser::parse);

It can also works with an iterable, an optional or even a collection
  Iterable<String> iterable = ...
  var stream = Stream.fromForEach(iterable::forEachRemaning);

  Optional<String> optional = ...
  var stream = Stream.fromForEach(optional::ifPresent);

  List<String> list = ...
  var stream = Stream.fromForEach(list::forEach);

I known the last two examples already have their own method stream(), it's just to explain how Stream.fromForEach is supposed to work.

In term of implementation, Stream.fromForEach() is equivalent to creating a stream using a mapMulti(), so it can be implemented like this

  static <T> Stream<T> fromForEach(Consumer<? super Consumer<T>> forEach) {
    return Stream.of((T) null).mapMulti((__, consumer) -> forEach.accept(consumer));
  }

but i think that Stream.fromForEach(iterable::forEachRemaning) is more readable than Stream.of(iterable).mapMult(Iterable::forEachRemaining).

The name fromForEach is not great and i'm sure someone will come with a better one.

regards,
R?mi

From kbarrett at openjdk.java.net  Sun May 22 03:18:48 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 22 May 2022 03:18:48 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <dVXnKoWIZQ8G3OcOYUpF6H1KYa3LKo_yJ7s1la_LrFg=.b86fe65e-c24b-4102-b1b6-9278411b9efb@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
 <dVXnKoWIZQ8G3OcOYUpF6H1KYa3LKo_yJ7s1la_LrFg=.b86fe65e-c24b-4102-b1b6-9278411b9efb@github.com>
Message-ID: <WF3f7m4GGhe4CuBndwnBYfpkniMZU9Qqr5jKBkfmVqQ=.53e34e3f-c820-4644-9616-d3db87d50cbc@github.com>

On Tue, 17 May 2022 12:38:55 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileParser.cpp line 5970:
>> 
>>> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED
>>> 5969:   _cp->symbol_at_put(hidden_index, _class_name);
>>> 5970: PRAGMA_DIAG_POP
>> 
>> I don't understand these warning suppressions for symbol_at_put (here and elsewhere).  I don't see any stringops here.  What is the compiler complaining about?  (There's no mention of classfile stuff in the review cover message.)
>
> Like the others, it is caused by `Array::at_put()`.
> 
> 
> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28,
>                  from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29,
>                  from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30,
>                  from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35:
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15,
>     inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21:

`Array<T>::_data` is a pseudo flexible array member. "Pseudo" because C++
doesn't have flexible array members. The compiler is completely justified in
complaining about the apparently out-of-bounds accesses.

There is a "well-known" (though moderately ugly) approach to doing flexible
array members in C++. Something like this:


T* data() {
  return reinterpret_cast<T*>(
    reinterpret_cast<char*>(this) + data_offset());
}


where `data_offset()` is new and private:


static size_t data_offset() {
  return offset_of(Array, _data);
}


Use `data()` everywhere instead of using `_data` directly.

There are other places in HotSpot that use this kind of approach.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From kbarrett at openjdk.java.net  Sun May 22 05:03:57 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 22 May 2022 05:03:57 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <hIsWyYSlUhRP7C95ZRVgCsbEM-16ZKIPg0Wf4u9OG5g=.81981efb-c599-4474-bbb9-d71786b6ab55@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
 <hIsWyYSlUhRP7C95ZRVgCsbEM-16ZKIPg0Wf4u9OG5g=.81981efb-c599-4474-bbb9-d71786b6ab55@github.com>
Message-ID: <iEuoewx3IZ0ZJpqpQQzrvvT3bHD_T58RrD6bI_DCUaY=.5ed80b90-f122-4ad3-8747-5a03dc3e8b31@github.com>

On Tue, 17 May 2022 12:43:02 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103:
>> 
>>> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED
>>> 102:   *dest = op(bits, *dest);
>>> 103: PRAGMA_DIAG_POP
>> 
>> I see no stringop here.  I'm still trying to understand what the compiler is complaining about.
>
> I guess GCC cannot understand `assert(dest != NULL` immediately preceding it.
> 
> 
> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33,
>                  from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30,
>                  from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30:
> In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]',
>     inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23,
>     inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6,
>     inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3,
>     inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35:

I don't think this warning has anything to do with that NULL check. But I'm
still not understanding what it is warning about. The "region of size 0" part
of the warning message seems important, but I'm not (yet?) seeing how it could
be coming up with that.  The code involved here is pretty contorted...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From cstein at openjdk.java.net  Sun May 22 06:07:22 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Sun, 22 May 2022 06:07:22 GMT
Subject: RFR: 8287121: Fix typo in jlink's description resource key lookup
Message-ID: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>

Commit https://github.com/openjdk/jdk/commit/655500a4f5e3abcff176599604deceefb6ca6640 for issue [JDK-8286654](https://bugs.openjdk.java.net/browse/JDK-8286654) added an optional description accessor on the `ToolProvider` interface. It included a typo in` jlink`'s description resource key lookup: `"jlink.desciption"`

This follow-up commit fixes the typo by adding the missing `r` character: `"jlink.description"`.

This commit also also adds an automated check that ensures all current and future tool provider implementations within the JDK don't throw an exception when invoking their name and description accessor methods. Specific tool names and descriptions are not expected by this general test.

-------------

Commit messages:
 - 8287121: Fix typo in jlink's description resource key lookup

Changes: https://git.openjdk.java.net/jdk/pull/8825/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8825&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287121
  Stats: 58 lines in 2 files changed: 57 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8825.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8825/head:pull/8825

PR: https://git.openjdk.java.net/jdk/pull/8825

From alanb at openjdk.java.net  Sun May 22 06:46:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 May 2022 06:46:45 GMT
Subject: RFR: 8287121: Fix typo in jlink's description resource key lookup
In-Reply-To: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
References: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
Message-ID: <_jNljOu0Jxmek6nT48nsCHyOS8a-PMTQVFyXCCG7SAk=.7e635c22-794f-4e5e-aeb9-17d66e8b4560@github.com>

On Sun, 22 May 2022 05:58:25 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Commit https://github.com/openjdk/jdk/commit/655500a4f5e3abcff176599604deceefb6ca6640 for issue [JDK-8286654](https://bugs.openjdk.java.net/browse/JDK-8286654) added an optional description accessor on the `ToolProvider` interface. It included a typo in` jlink`'s description resource key lookup: `"jlink.desciption"`
> 
> This follow-up commit fixes the typo by adding the missing `r` character: `"jlink.description"`.
> 
> This commit also also adds an automated check that ensures all current and future tool provider implementations within the JDK don't throw an exception when invoking their name and description accessor methods. Specific tool names and descriptions are not expected by this general test.

test/jdk/java/util/spi/ToolProviderDescriptionTest.java line 46:

> 44: 
> 45:     static List<String> listToolDescriptions() {
> 46:         return StreamSupport.stream(ServiceLoader.load(ToolProvider.class).spliterator(), false)

it doesn't matter for this test but SL does have a stream method that could be used instead:

ServiceLoader.load(ToolProvider.class)
     .stream()
    .map(ServiceLoader.Provider::get)
    .sorted(Comparator.comparing(ToolProvider::name))
    ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8825

From ysuenaga at openjdk.java.net  Sun May 22 08:40:28 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 22 May 2022 08:40:28 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8]
In-Reply-To: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
Message-ID: <P_IG4tyJ06FNFBIiStcveZPGkbB1OGIrri3Iz31LFBA=.4fc4c7f5-2afd-4ac2-924f-06a271893368@github.com>

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
> 
> * -Wstringop-overflow
>     * src/hotspot/share/oops/array.hpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
> 
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge remote-tracking branch 'upstream/master' into gcc12-warnings
 - Use getter function to access "_data"
 - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp
 - revert changes for memnode.cpp and type.cpp
 - Add assert to check the range of BasicType
 - Merge remote-tracking branch 'upstream/master' into HEAD
 - Revert change for java.c , parse_manifest.c , LinuxPackage.c
 - Calculate char offset before realloc()
 - Use return value from JLI_Snprintf
 - Avoid pragma error in before GCC 12
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8646/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=07
  Stats: 42 lines in 7 files changed: 26 ins; 1 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Sun May 22 08:40:28 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 22 May 2022 08:40:28 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <WF3f7m4GGhe4CuBndwnBYfpkniMZU9Qqr5jKBkfmVqQ=.53e34e3f-c820-4644-9616-d3db87d50cbc@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
 <dVXnKoWIZQ8G3OcOYUpF6H1KYa3LKo_yJ7s1la_LrFg=.b86fe65e-c24b-4102-b1b6-9278411b9efb@github.com>
 <WF3f7m4GGhe4CuBndwnBYfpkniMZU9Qqr5jKBkfmVqQ=.53e34e3f-c820-4644-9616-d3db87d50cbc@github.com>
Message-ID: <d-4Z0WMG5wjU8BKd-jwh6A-nS4sKsY_7CD8hcSIT6VE=.ee8cc988-9b8d-4909-86b8-c7b29e8f257e@github.com>

On Sun, 22 May 2022 03:15:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Like the others, it is caused by `Array::at_put()`.
>> 
>> 
>> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28,
>>                  from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29,
>>                  from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30,
>>                  from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35:
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15,
>>     inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21:
>
> `Array<T>::_data` is a pseudo flexible array member. "Pseudo" because C++
> doesn't have flexible array members. The compiler is completely justified in
> complaining about the apparently out-of-bounds accesses.
> 
> There is a "well-known" (though moderately ugly) approach to doing flexible
> array members in C++. Something like this:
> 
> 
> T* data() {
>   return reinterpret_cast<T*>(
>     reinterpret_cast<char*>(this) + data_offset());
> }
> 
> 
> where `data_offset()` is new and private:
> 
> 
> static size_t data_offset() {
>   return offset_of(Array, _data);
> }
> 
> 
> Use `data()` everywhere instead of using `_data` directly.
> 
> There are other places in HotSpot that use this kind of approach.

Thanks @kimbarrett for your advice! Warnings from array.hpp have gone with your suggestion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Sun May 22 08:48:47 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 22 May 2022 08:48:47 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <iEuoewx3IZ0ZJpqpQQzrvvT3bHD_T58RrD6bI_DCUaY=.5ed80b90-f122-4ad3-8747-5a03dc3e8b31@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
 <hIsWyYSlUhRP7C95ZRVgCsbEM-16ZKIPg0Wf4u9OG5g=.81981efb-c599-4474-bbb9-d71786b6ab55@github.com>
 <iEuoewx3IZ0ZJpqpQQzrvvT3bHD_T58RrD6bI_DCUaY=.5ed80b90-f122-4ad3-8747-5a03dc3e8b31@github.com>
Message-ID: <FftdUZXstTbgJoJ3uSN6IX9ectw1cZ_XOSSwk6v4PR0=.96511671-96b3-4bce-a1e6-cf0120a20b48@github.com>

On Sun, 22 May 2022 05:00:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I guess GCC cannot understand `assert(dest != NULL` immediately preceding it.
>> 
>> 
>> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33,
>>                  from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30,
>>                  from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30:
>> In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]',
>>     inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23,
>>     inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6,
>>     inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3,
>>     inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35:
>
> I don't think this warning has anything to do with that NULL check. But I'm
> still not understanding what it is warning about. The "region of size 0" part
> of the warning message seems important, but I'm not (yet?) seeing how it could
> be coming up with that.  The code involved here is pretty contorted...

It might be GCC bug...

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578

This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From kbarrett at openjdk.java.net  Sun May 22 16:44:58 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 22 May 2022 16:44:58 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <d-4Z0WMG5wjU8BKd-jwh6A-nS4sKsY_7CD8hcSIT6VE=.ee8cc988-9b8d-4909-86b8-c7b29e8f257e@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
 <dVXnKoWIZQ8G3OcOYUpF6H1KYa3LKo_yJ7s1la_LrFg=.b86fe65e-c24b-4102-b1b6-9278411b9efb@github.com>
 <WF3f7m4GGhe4CuBndwnBYfpkniMZU9Qqr5jKBkfmVqQ=.53e34e3f-c820-4644-9616-d3db87d50cbc@github.com>
 <d-4Z0WMG5wjU8BKd-jwh6A-nS4sKsY_7CD8hcSIT6VE=.ee8cc988-9b8d-4909-86b8-c7b29e8f257e@github.com>
Message-ID: <3CBxbI5futoRYrvWQY5-0hUsWNb8fsZWF2goyqFOgY0=.0328a1d2-126e-4f5f-a6d7-ba638499eefd@github.com>

On Sun, 22 May 2022 08:35:54 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `Array<T>::_data` is a pseudo flexible array member. "Pseudo" because C++
>> doesn't have flexible array members. The compiler is completely justified in
>> complaining about the apparently out-of-bounds accesses.
>> 
>> There is a "well-known" (though moderately ugly) approach to doing flexible
>> array members in C++. Something like this:
>> 
>> 
>> T* data() {
>>   return reinterpret_cast<T*>(
>>     reinterpret_cast<char*>(this) + data_offset());
>> }
>> 
>> 
>> where `data_offset()` is new and private:
>> 
>> 
>> static size_t data_offset() {
>>   return offset_of(Array, _data);
>> }
>> 
>> 
>> Use `data()` everywhere instead of using `_data` directly.
>> 
>> There are other places in HotSpot that use this kind of approach.
>
> Thanks @kimbarrett for your advice! Warnings from array.hpp have gone with your suggestion.

Good.  I see you found and used the existing `base_offset_in_bytes` (which I'd overlooked), rather than using my suggested `data_offset`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From kbarrett at openjdk.java.net  Sun May 22 16:48:42 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 22 May 2022 16:48:42 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <FftdUZXstTbgJoJ3uSN6IX9ectw1cZ_XOSSwk6v4PR0=.96511671-96b3-4bce-a1e6-cf0120a20b48@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
 <hIsWyYSlUhRP7C95ZRVgCsbEM-16ZKIPg0Wf4u9OG5g=.81981efb-c599-4474-bbb9-d71786b6ab55@github.com>
 <iEuoewx3IZ0ZJpqpQQzrvvT3bHD_T58RrD6bI_DCUaY=.5ed80b90-f122-4ad3-8747-5a03dc3e8b31@github.com>
 <FftdUZXstTbgJoJ3uSN6IX9ectw1cZ_XOSSwk6v4PR0=.96511671-96b3-4bce-a1e6-cf0120a20b48@github.com>
Message-ID: <GYt9l65QBdx5_vIHgqckWcxDM8SZ1nCvxAOtk_jP_lI=.468be262-aa88-412f-9524-37241140df57@github.com>

On Sun, 22 May 2022 08:45:48 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I don't think this warning has anything to do with that NULL check. But I'm
>> still not understanding what it is warning about. The "region of size 0" part
>> of the warning message seems important, but I'm not (yet?) seeing how it could
>> be coming up with that.  The code involved here is pretty contorted...
>
> It might be GCC bug...
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
> 
> This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`).

I don't see the similarity.  That gcc bug is about literals used as addresses,
which get treated (suggested inappropriately) as NULL+offset, with NULL+offset
being a cause of warnings.  I don't see that happening in our case.  That is,
in our `addr + low_offset`, `addr` doesn't seem to be either a literal or NULL
that I can see.

It's hard for me to investigate this any further just by perusing the code, so
I'm in the process of getting set up to build with gcc12.x.  That will let me
do some experiments. It may take me a few days to get to that point though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From plevart at openjdk.java.net  Sun May 22 16:57:50 2022
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 22 May 2022 16:57:50 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
Message-ID: <yhHfsS3mRvGIhSXQ1SAwPTvV-lT3kQDH7Z8XIC2_7UY=.04aace51-3945-45d7-a56d-e43bf1cdab04@github.com>

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected LimitedImage test description

My humble opinion: if java.compiler needs jdk.zipfs for full functionality (i.e. using --source N or --release X), does that mean java.compiler is useless without jdk.zipfs? If there is a meaningful functionality left in java.compiler even without jdk.zipfs, then someone might want to use that limited subset of functionality and might not want to include jdk.zipfs in its image.
So what is possible to do with java.compiler without jdk.zipfs?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8747

From plevart at openjdk.java.net  Sun May 22 17:07:44 2022
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 22 May 2022 17:07:44 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <yhHfsS3mRvGIhSXQ1SAwPTvV-lT3kQDH7Z8XIC2_7UY=.04aace51-3945-45d7-a56d-e43bf1cdab04@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
 <yhHfsS3mRvGIhSXQ1SAwPTvV-lT3kQDH7Z8XIC2_7UY=.04aace51-3945-45d7-a56d-e43bf1cdab04@github.com>
Message-ID: <X6bZR1w_7ORxLKR--p3kNLM-cqmKIThAU3OV2aJohWQ=.902cf742-280e-4d59-9990-636adda62c1b@github.com>

On Sun, 22 May 2022 16:54:25 GMT, Peter Levart <plevart at openjdk.org> wrote:

> My humble opinion: if java.compiler needs jdk.zipfs for full functionality....

Sorry, I wrongly assumed it was `java.compiler` (the library module), but this is about `jdk.compiler` (the tool)... Nevertheless, the same question applies: Does `jdk.compiler` have any meaningful functionality even without `jdk.zipfs` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8747

From aturbanov at openjdk.java.net  Sun May 22 20:22:41 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sun, 22 May 2022 20:22:41 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <GMGWQhNckhBCqioWrC4enqwuc-_w7QF349mOOcWNvzA=.c0e52085-98be-4401-8e13-2cb71536c0fa@github.com>

On Wed, 6 Apr 2022 17:47:53 GMT, Chris Hennick <duke at openjdk.java.net> wrote:

> Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around 2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1); this fixes that by tracking the multiple of exponentialX0 as a long. (This changes the maximum possible output to `1.0p63 * DoubleZigguratTables.exponentialX0 == 0x1.e46eff20739afp65`; previously it would have been `0x1.0p56` because once `extra` reaches that amount, `x + extra == extra` due to the rounding error. This lowers the probability of reaching the maximum with an ideal PRNG from about `1.3877787807814488E-17` to about `1.4323726067488646E-20` (calculated using the identity `ln(x) == Math.log10(x)/Math.log10(Math.exp(1))`).

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1411:

> 1409:                 long U2 = (rng.nextLong() >>> 1);
> 1410:                 // Compute the actual x-coordinate of the randomly chosen point.
> 1411:                 x = Math.fma(X[j-1] - X[j], (double)U1, X[j] * 0x1.0p63));

Code is not compilable

-------------

PR: https://git.openjdk.java.net/jdk/pull/8131

From shade at openjdk.java.net  Mon May 23 05:47:48 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 05:47:48 GMT
Subject: RFR: 8286956: Loom: Define test groups for development/porting use
In-Reply-To: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
References: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
Message-ID: <ZU8nipii4IvtjOLpT-CASGxRpX_0RTmtzauYlGLMk10=.b986ecb1-5a80-4834-9c1f-88347eb8b327@github.com>

On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work.
> 
> https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
> https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125
> 
> I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom`
>  - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom`

Anyone?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8765

From amaembo at gmail.com  Mon May 23 06:01:44 2022
From: amaembo at gmail.com (Tagir Valeev)
Date: Mon, 23 May 2022 13:01:44 +0700
Subject: <T> Stream.fromForEach(Consumer<Consumer<T>>)
In-Reply-To: <1144676012.11391840.1653173645995.JavaMail.zimbra@u-pem.fr>
References: <1144676012.11391840.1653173645995.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAE+3fjYxo6RDRcXmMdKSYVNNqDBHHESegiBWrN2Z2Kjoha-VuA@mail.gmail.com>

Hello!

There's a Stream.builder for this purpose:

var builder = Stream.<String>builder();
new Parser("1 2 3").parse(builder);
builder.build().forEach(System.out::println);

A little bit more verbose than your suggestion but this way it's more
clear that the whole stream content will be buffered.

With best regards,
Tagir Valeev

On Sun, May 22, 2022 at 5:54 AM Remi Forax <forax at univ-mlv.fr> wrote:
>
> Hi all,
> a stream is kind of push iterator so it can be created from any object that has a method like forEach(Consumer),
> but sadly there is no static method to create a Stream from a Consumer of Consumer so people usually miss that creating a Stream from events pushed to a consumer is easy.
>
> By example, let say i've a very simple parser like this, it calls the listener/callback for each tokens
>
>   record Parser(String text) {
>     void parse(Consumer<? super String> listener) {
>       for(var token: text.split(" ")) {
>          listener.accept(token);
>       }
>     }
>   }
>
> Using the method Stream.fromForEach, we can create a Stream from the sequence of tokens that are pushed through the listener
>   var parser = new Parser("1 2");
>   var stream = Stream.fromForEach(parser::parse);
>
> It can also works with an iterable, an optional or even a collection
>   Iterable<String> iterable = ...
>   var stream = Stream.fromForEach(iterable::forEachRemaning);
>
>   Optional<String> optional = ...
>   var stream = Stream.fromForEach(optional::ifPresent);
>
>   List<String> list = ...
>   var stream = Stream.fromForEach(list::forEach);
>
> I known the last two examples already have their own method stream(), it's just to explain how Stream.fromForEach is supposed to work.
>
> In term of implementation, Stream.fromForEach() is equivalent to creating a stream using a mapMulti(), so it can be implemented like this
>
>   static <T> Stream<T> fromForEach(Consumer<? super Consumer<T>> forEach) {
>     return Stream.of((T) null).mapMulti((__, consumer) -> forEach.accept(consumer));
>   }
>
> but i think that Stream.fromForEach(iterable::forEachRemaning) is more readable than Stream.of(iterable).mapMult(Iterable::forEachRemaining).
>
> The name fromForEach is not great and i'm sure someone will come with a better one.
>
> regards,
> R?mi

From forax at univ-mlv.fr  Mon May 23 06:08:24 2022
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 23 May 2022 08:08:24 +0200 (CEST)
Subject: <T> Stream.fromForEach(Consumer<Consumer<T>>)
In-Reply-To: <CAE+3fjYxo6RDRcXmMdKSYVNNqDBHHESegiBWrN2Z2Kjoha-VuA@mail.gmail.com>
References: <1144676012.11391840.1653173645995.JavaMail.zimbra@u-pem.fr>
 <CAE+3fjYxo6RDRcXmMdKSYVNNqDBHHESegiBWrN2Z2Kjoha-VuA@mail.gmail.com>
Message-ID: <930593472.11699067.1653286104737.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Tagir Valeev" <amaembo at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Monday, May 23, 2022 8:01:44 AM
> Subject: Re: <T> Stream.fromForEach(Consumer<Consumer<T>>)

> Hello!
> 
> There's a Stream.builder for this purpose:
> 
> var builder = Stream.<String>builder();
> new Parser("1 2 3").parse(builder);
> builder.build().forEach(System.out::println);
> 
> A little bit more verbose than your suggestion but this way it's more
> clear that the whole stream content will be buffered.

I should have mentioned the Stream.builder, as you said, the Stream.Builder stores the whole elements in memory before creating the stream,
it's equivalent to storing the elements in a List and calling List.stream.

Stream.fromForEach like stream.mapMulti() does not stores the elements.
(technically, stream.mapMulti() stores the elements if the default method implementation is used but this implementation is only used if you write your own Stream, the JDK implementation does not store the elements)

> 
> With best regards,
> Tagir Valeev

regards,
R?mi

> 
> On Sun, May 22, 2022 at 5:54 AM Remi Forax <forax at univ-mlv.fr> wrote:
>>
>> Hi all,
>> a stream is kind of push iterator so it can be created from any object that has
>> a method like forEach(Consumer),
>> but sadly there is no static method to create a Stream from a Consumer of
>> Consumer so people usually miss that creating a Stream from events pushed to a
>> consumer is easy.
>>
>> By example, let say i've a very simple parser like this, it calls the
>> listener/callback for each tokens
>>
>>   record Parser(String text) {
>>     void parse(Consumer<? super String> listener) {
>>       for(var token: text.split(" ")) {
>>          listener.accept(token);
>>       }
>>     }
>>   }
>>
>> Using the method Stream.fromForEach, we can create a Stream from the sequence of
>> tokens that are pushed through the listener
>>   var parser = new Parser("1 2");
>>   var stream = Stream.fromForEach(parser::parse);
>>
>> It can also works with an iterable, an optional or even a collection
>>   Iterable<String> iterable = ...
>>   var stream = Stream.fromForEach(iterable::forEachRemaning);
>>
>>   Optional<String> optional = ...
>>   var stream = Stream.fromForEach(optional::ifPresent);
>>
>>   List<String> list = ...
>>   var stream = Stream.fromForEach(list::forEach);
>>
>> I known the last two examples already have their own method stream(), it's just
>> to explain how Stream.fromForEach is supposed to work.
>>
>> In term of implementation, Stream.fromForEach() is equivalent to creating a
>> stream using a mapMulti(), so it can be implemented like this
>>
>>   static <T> Stream<T> fromForEach(Consumer<? super Consumer<T>> forEach) {
>>     return Stream.of((T) null).mapMulti((__, consumer) -> forEach.accept(consumer));
>>   }
>>
>> but i think that Stream.fromForEach(iterable::forEachRemaning) is more readable
>> than Stream.of(iterable).mapMult(Iterable::forEachRemaining).
>>
>> The name fromForEach is not great and i'm sure someone will come with a better
>> one.
>>
>> regards,
> > R?mi

From rehn at openjdk.java.net  Mon May 23 06:08:43 2022
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Mon, 23 May 2022 06:08:43 GMT
Subject: RFR: 8286825: Linker naming cleanup [v2]
In-Reply-To: <Q9b-ESFS_MVQK-fOPmvNf_LuNM5bGs9hW6vzL-dwXc0=.0352e21f-3cde-414c-9dbe-f15c11c1e01e@github.com>
References: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
 <Q9b-ESFS_MVQK-fOPmvNf_LuNM5bGs9hW6vzL-dwXc0=.0352e21f-3cde-414c-9dbe-f15c11c1e01e@github.com>
Message-ID: <x54nR0TFI5NBjKMlvxJSfXQZIYOQVS10hDpmfiasKDQ=.674eb555-87b3-445a-a422-0529951a455d@github.com>

On Fri, 20 May 2022 10:57:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch is a batch naming cleanup for the foreign linker implementation.
>> 
>> The naming changes are as follows:
>> 
>>   - ProgrammableInvoker -> DowncallLinker
>>   - ProgrammableUpcallHandler -> UpcallLinker
>>   - 'native invoker' -> 'downcall stub'
>>   - 'optimzed entry blob' -> 'upcall stub'
>>   - OptimizedEntryBlob -> UpcallStub
>>   - optimized_entry_frame -> upcall_stub_frame
>> 
>> Then renaming of some hotspot files:
>> 
>>   - universalNativeInvoker* -> downcallLinker*
>>   - universalUpcallHandler* -> upcallLinker*
>>   - foreign_globals* -> foreignGlobals* (to match existing convention)
>>   
>> Method, field, and other variable names are also adjusted accordingly.
>> 
>> Testing: Tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments + cleanup

Note that some find downcall/upcall unintuitive.
We may need revisit this.

Thanks

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8777

From asotona at openjdk.java.net  Mon May 23 07:33:37 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 07:33:37 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <X6bZR1w_7ORxLKR--p3kNLM-cqmKIThAU3OV2aJohWQ=.902cf742-280e-4d59-9990-636adda62c1b@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
 <yhHfsS3mRvGIhSXQ1SAwPTvV-lT3kQDH7Z8XIC2_7UY=.04aace51-3945-45d7-a56d-e43bf1cdab04@github.com>
 <X6bZR1w_7ORxLKR--p3kNLM-cqmKIThAU3OV2aJohWQ=.902cf742-280e-4d59-9990-636adda62c1b@github.com>
Message-ID: <Q0qA-WGcGFlsJ0qGFSl5-QpDNMaGW_cNfzeHUCIY8Wk=.f941db3d-646d-4247-8e78-65a74b88fe87@github.com>

On Sun, 22 May 2022 17:04:30 GMT, Peter Levart <plevart at openjdk.org> wrote:

> > My humble opinion: if java.compiler needs jdk.zipfs for full functionality....
> 
> Sorry, I wrongly assumed it was `java.compiler` (the library module), but this is about `jdk.compiler` (the tool)... Nevertheless, the same question applies: Does `jdk.compiler` have any meaningful functionality even without `jdk.zipfs` ?

Basic compilation works even without presence of jdk.zipfs, however such stripped JDK is for example unable to read jar files on classpath.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8747

From alanb at openjdk.java.net  Mon May 23 08:21:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 08:21:40 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <Q0qA-WGcGFlsJ0qGFSl5-QpDNMaGW_cNfzeHUCIY8Wk=.f941db3d-646d-4247-8e78-65a74b88fe87@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
 <yhHfsS3mRvGIhSXQ1SAwPTvV-lT3kQDH7Z8XIC2_7UY=.04aace51-3945-45d7-a56d-e43bf1cdab04@github.com>
 <X6bZR1w_7ORxLKR--p3kNLM-cqmKIThAU3OV2aJohWQ=.902cf742-280e-4d59-9990-636adda62c1b@github.com>
 <Q0qA-WGcGFlsJ0qGFSl5-QpDNMaGW_cNfzeHUCIY8Wk=.f941db3d-646d-4247-8e78-65a74b88fe87@github.com>
Message-ID: <_si3TMfeqHv-HR4Py0KhM2MKJRqOt1hILTuHLThFEu0=.9f38b4d5-158e-4361-8024-814e720e195a@github.com>

On Mon, 23 May 2022 07:29:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Sorry, I wrongly assumed it was `java.compiler` (the library module), but this is about `jdk.compiler` (the tool)... Nevertheless, the same question applies: Does `jdk.compiler` have any meaningful functionality even without `jdk.zipfs` ?

This came up in JDK 9 and the decision at the time was not to require jdk.zipfs as it's a service provider module. The addition of the source launcher, the addition of --enable-preview, and more use of --release N means more ct.sym usage. It probably isn't too interesting to have a small runtime image that contains jdk.compiler and not jdk.zipfs so Adam's proposal mightn't be too bad, it's just a bit weird and not something that we'd want other libraries in the eco system to do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8747

From aturbanov at openjdk.java.net  Mon May 23 08:32:02 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 23 May 2022 08:32:02 GMT
Subject: Integrated: 8287053: Avoid redundant HashMap.containsKey calls in
 ZoneInfoFile.getZoneInfo0
In-Reply-To: <LlL9rKAuLvh_eGitin7ESJnZUOePjHhtYyuLuoa2hsU=.34ef6d1f-1dbd-409c-b049-fc783ba17bb5@github.com>
References: <LlL9rKAuLvh_eGitin7ESJnZUOePjHhtYyuLuoa2hsU=.34ef6d1f-1dbd-409c-b049-fc783ba17bb5@github.com>
Message-ID: <svjMKmYxfT-OUr13tPZQs4-fSbrzTtmKpj3tJAkWFUE=.6c56e57a-9d34-4c39-9f98-5ea61a01ed69@github.com>

On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`.
> It's faster and clearer.

This pull request has now been integrated.

Changeset: 01916e19
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/01916e192039bebbb93f5a09eb3ca9ec31ee707f
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8287053: Avoid redundant HashMap.containsKey calls in ZoneInfoFile.getZoneInfo0

Reviewed-by: redestad, naoto, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8487

From mcimadamore at openjdk.java.net  Mon May 23 08:47:57 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 May 2022 08:47:57 GMT
Subject: Integrated: 8286715: Generalize MemorySegment::ofBuffer
In-Reply-To: <zeaLhFMyC1279aCYqNzyT23OI6AXiUxzkWNS68yJbQs=.55dd8eec-7f94-4897-9cab-2d4485ff05cc@github.com>
References: <zeaLhFMyC1279aCYqNzyT23OI6AXiUxzkWNS68yJbQs=.55dd8eec-7f94-4897-9cab-2d4485ff05cc@github.com>
Message-ID: <vmCIXCQy8Tx2dT0gH2NWMkZlvysQeFstvrRoxXdm144=.20048075-597a-43fc-83b7-146709d217aa@github.com>

On Fri, 13 May 2022 12:33:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch makes MemorySegment::ofBuffer more general, by allowing clients to pass *any* `Buffer` instance, not just `ByteBuffer`.
> This allows us to match expressiveness of JNI API, where JNI clients can obtain the address of any direct buffer instance, using the `GetDirectBufferAddress` function.
> 
> We thought about also providing a more general way to view a segment as a buffer (e.g. asIntBuffer) but doing that doesn't seem worth it: direct buffers can only created form `ByteBuffer`.
> So, to create a direct `IntBuffer`, clients have to first create a direct `ByteBuffer` then to view that buffer as an `IntBuffer`.
> 
> In other words, `IntBuffer` and friends are not first-class citizens in the `Buffer` API. As such it would not be possible to map many memory segments into an `IntBuffer`; in fact, the only segment we could safely map into an `IntBuffer` would be an _heap_ segment backed by an `int[]`. As such it doesn't seem worth adding a lot of API surface (in terms of additional overloads) for such a corner case.

This pull request has now been integrated.

Changeset: 89a1d055
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/89a1d055d93ad57bcec7c1accb3f53b4c30f594d
Stats:     95 lines in 8 files changed: 55 ins; 1 del; 39 mod

8286715: Generalize MemorySegment::ofBuffer

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.java.net/jdk/pull/8701

From cstein at openjdk.java.net  Mon May 23 08:59:09 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 23 May 2022 08:59:09 GMT
Subject: RFR: 8279031: Add API note to ToolProvider about being
 reusable/reentrant
Message-ID: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>

This commit adds an  API note to ToolProvider about being reusable/reentrant.

-------------

Commit messages:
 - 8286815: Add API note to ToolProvider about being reusable/reentrant

Changes: https://git.openjdk.java.net/jdk/pull/8833/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8833&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279031
  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8833.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8833/head:pull/8833

PR: https://git.openjdk.java.net/jdk/pull/8833

From alanb at openjdk.java.net  Mon May 23 09:07:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 09:07:48 GMT
Subject: RFR: 8287121: Fix typo in jlink's description resource key lookup
In-Reply-To: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
References: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
Message-ID: <4hUI_Bv49Ix01YqH5GLMtBnYrykIuet0frUfUToz3K8=.9e61a45a-24c0-4088-b536-598e4e2afc71@github.com>

On Sun, 22 May 2022 05:58:25 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Commit https://github.com/openjdk/jdk/commit/655500a4f5e3abcff176599604deceefb6ca6640 for issue [JDK-8286654](https://bugs.openjdk.java.net/browse/JDK-8286654) added an optional description accessor on the `ToolProvider` interface. It included a typo in` jlink`'s description resource key lookup: `"jlink.desciption"`
> 
> This follow-up commit fixes the typo by adding the missing `r` character: `"jlink.description"`.
> 
> This commit also also adds an automated check that ensures all current and future tool provider implementations within the JDK don't throw an exception when invoking their name and description accessor methods. Specific tool names and descriptions are not expected by this general test.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8825

From sgehwolf at openjdk.java.net  Mon May 23 09:27:45 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 23 May 2022 09:27:45 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <fRitJVBN5BS8dbJ0VvMDkFZ65xpDJvhd5KlCKk5DhMI=.ca576f15-5b74-48d3-b46a-1432780ad016@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
 <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>
 <bPoDNxABi63JebXkYflJ3FUR0IF8OieXLmwkwjIxmk8=.1651330e-59af-4f56-932e-08d37626dfe9@github.com>
 <fRitJVBN5BS8dbJ0VvMDkFZ65xpDJvhd5KlCKk5DhMI=.ca576f15-5b74-48d3-b46a-1432780ad016@github.com>
Message-ID: <KPDr-0LR7sXWsSUW5w_0Qbuh-MXaddpNBO6s5Lsd8_U=.80b1eb53-c1f9-4e8a-8ac7-7f8b092008cc@github.com>

On Thu, 19 May 2022 20:18:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I am wondering if the problem is this:
>> 
>> We have systemd running on the host, and a different copy of systemd that runs inside the container.
>> 
>> - They both set up `/user.slice/user-1000.slice/session-??.scope` within their own file systems
>> - For some reason, when you're looking inside the container, `/proc/self/cgroup` might use a path in the containerized file system whereas `/proc/self/mountinfo` uses a path in the host file system. These two paths may look alike but they have absolutely no relation to each other.
>> 
>> I have asked the reporter for more information:
>> 
>> https://gist.github.com/gaol/4d96eace8290e6549635fdc0ea41d0b4?permalink_comment_id=4172593#gistcomment-4172593
>> 
>> Meanwhile, I think the current method of finding "which directory under /sys/fs/cgroup/memory controls my memory usage" is broken. As mentioned about, the path you get from  `/proc/self/cgroup`  and `/proc/self/mountinfo` have no relation to each other, but we use them anyway to get our answer, with many ad-hoc methods that are not documented in the code.
>> 
>> Maybe we should do this instead?
>> 
>> - Read /proc/self/cgroup
>> - Find the `10:memory:<path>` line
>> - If `/sys/fs/cgroup/memory/<path>/tasks` contains my PID, this is the path
>> - Otherwise, scan all `tasks` files under  `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID.
>> 
>> For example, here's a test with docker:
>> 
>> 
>> INSIDE CONTAINER
>> # cat /proc/self/cgroup | grep memory
>> 10:memory:/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050
>> # cat /proc/self/mountinfo | grep memory
>> 801 791 0:42 /docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050 /sys/fs/cgroup/memory ro,nosuid,nodev,noexec,relatime master:23 - cgroup cgroup rw,memory
>> # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
>> cat: /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks: No such file or directory
>> # cat /sys/fs/cgroup/memory/tasks | grep $$
>> 1
>> 
>> ON HOST
>> # cat /sys/fs/cgroup/memory/docker/40ea0ab8eaa0469d8d852b7f1d264b6a451a1c2fe20924cd2de874da5f2e3050/tasks
>> 37494
>> # cat /proc/37494/status | grep NSpid
>> NSpid:	37494	1
>
> Also, I think the current PR could produce the wrong answer, if systemd is indeed running inside the container, and we have:
> 
> 
> "/user.slice/user-1000.slice/session-50.scope",    // root_path
> "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
> 
> 
> The PR gives /sys/fs/cgroup/memory/user.slice/user-1000.slice/, which specifies the overall memory limit for user-1000. However, the correct answer may be /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-3.scope, which may have a smaller memory limit, and the JVM may end up allocating a larger heap than allowed.

Yes, if we can decide which one the right file is. This is largely undocumented territory. The correct fix is a) find the correct path to the namespace hierarchy the process is a part of. b) starting at the leaf node, walk up the hierarchy and find the **lowest** limits. Doing this would be very expensive!

Aside: Current container detection in the JVM/JDK is notoriously imprecise. It's largely based on common setups (containers like docker). The heuristics assume that memory limits are reported inside the container at the leaf node. If, however, that's not the case, the detected limits will be wrong (it will detect it as unlimited, even though it's - for example - memory constrained at the parent). This can for example be reproduced on a cgroups v2 system with a systemd slice using memory limits. We've worked-around this in OpenJDK for cgroups v1 by https://bugs.openjdk.java.net/browse/JDK-8217338

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From jvernee at openjdk.java.net  Mon May 23 09:52:49 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 May 2022 09:52:49 GMT
Subject: RFR: 8286825: Linker naming cleanup [v2]
In-Reply-To: <Q9b-ESFS_MVQK-fOPmvNf_LuNM5bGs9hW6vzL-dwXc0=.0352e21f-3cde-414c-9dbe-f15c11c1e01e@github.com>
References: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
 <Q9b-ESFS_MVQK-fOPmvNf_LuNM5bGs9hW6vzL-dwXc0=.0352e21f-3cde-414c-9dbe-f15c11c1e01e@github.com>
Message-ID: <WkMfUWCr26KNDkC41CdoBltVJ7wtRiI5LS42HJEAbw4=.6427d008-268b-48a6-932c-1bec29b70452@github.com>

On Fri, 20 May 2022 10:57:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch is a batch naming cleanup for the foreign linker implementation.
>> 
>> The naming changes are as follows:
>> 
>>   - ProgrammableInvoker -> DowncallLinker
>>   - ProgrammableUpcallHandler -> UpcallLinker
>>   - 'native invoker' -> 'downcall stub'
>>   - 'optimzed entry blob' -> 'upcall stub'
>>   - OptimizedEntryBlob -> UpcallStub
>>   - optimized_entry_frame -> upcall_stub_frame
>> 
>> Then renaming of some hotspot files:
>> 
>>   - universalNativeInvoker* -> downcallLinker*
>>   - universalUpcallHandler* -> upcallLinker*
>>   - foreign_globals* -> foreignGlobals* (to match existing convention)
>>   
>> Method, field, and other variable names are also adjusted accordingly.
>> 
>> Testing: Tier 1-4
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments + cleanup

Thanks. The down/upcall terminology is the one we use in the public Java API as well, so using that everywhere seems the most consistent.

I'm fine with revisiting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8777

From jvernee at openjdk.java.net  Mon May 23 10:06:44 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 May 2022 10:06:44 GMT
Subject: Integrated: 8286825: Linker naming cleanup
In-Reply-To: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
References: <KXQDk4v-0KV51bB4fLMfv2Vx80ZrhQ7KyxOLAQmrp80=.f6e14b18-3224-4eac-8a85-0c76b99e02f8@github.com>
Message-ID: <63AOhjcTxGFhNJBpD3xHUQE3TfcaEeT38u5I8bXAg-8=.bab2b4d0-20db-4f3d-956c-64db99e6247b@github.com>

On Wed, 18 May 2022 16:54:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch is a batch naming cleanup for the foreign linker implementation.
> 
> The naming changes are as follows:
> 
>   - ProgrammableInvoker -> DowncallLinker
>   - ProgrammableUpcallHandler -> UpcallLinker
>   - 'native invoker' -> 'downcall stub'
>   - 'optimzed entry blob' -> 'upcall stub'
>   - OptimizedEntryBlob -> UpcallStub
>   - optimized_entry_frame -> upcall_stub_frame
> 
> Then renaming of some hotspot files:
> 
>   - universalNativeInvoker* -> downcallLinker*
>   - universalUpcallHandler* -> upcallLinker*
>   - foreign_globals* -> foreignGlobals* (to match existing convention)
>   
> Method, field, and other variable names are also adjusted accordingly.
> 
> Testing: Tier 1-4

This pull request has now been integrated.

Changeset: 7becf13e
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7becf13e61ba2c43837e4b48775fdaf73bc1d79e
Stats:     3181 lines in 85 files changed: 1487 ins; 1491 del; 203 mod

8286825: Linker naming cleanup

Reviewed-by: mcimadamore, rehn

-------------

PR: https://git.openjdk.java.net/jdk/pull/8777

From lancea at openjdk.java.net  Mon May 23 10:14:54 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 23 May 2022 10:14:54 GMT
Subject: RFR: 8279031: Add API note to ToolProvider about being
 reusable/reentrant
In-Reply-To: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
References: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
Message-ID: <0e8qaaVfPOmrOIiZATYTRN6rEvA6WPKdBAx38VQc1ds=.0a701f84-60bf-4655-a5d7-fed6d9e892e9@github.com>

On Mon, 23 May 2022 08:49:27 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This commit adds an  API note to ToolProvider about being reusable/reentrant.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8833

From lancea at openjdk.java.net  Mon May 23 10:19:54 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 23 May 2022 10:19:54 GMT
Subject: RFR: 8287121: Fix typo in jlink's description resource key lookup
In-Reply-To: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
References: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
Message-ID: <VbOWPxfLsPIOb-4HQe69aY2klVq1eXBV5DNM97bSxvY=.e1b25498-05b2-4080-81bf-7d9ca791a92a@github.com>

On Sun, 22 May 2022 05:58:25 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Commit https://github.com/openjdk/jdk/commit/655500a4f5e3abcff176599604deceefb6ca6640 for issue [JDK-8286654](https://bugs.openjdk.java.net/browse/JDK-8286654) added an optional description accessor on the `ToolProvider` interface. It included a typo in` jlink`'s description resource key lookup: `"jlink.desciption"`
> 
> This follow-up commit fixes the typo by adding the missing `r` character: `"jlink.description"`.
> 
> This commit also also adds an automated check that ensures all current and future tool provider implementations within the JDK don't throw an exception when invoking their name and description accessor methods. Specific tool names and descriptions are not expected by this general test.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8825

From cstein at openjdk.java.net  Mon May 23 10:38:43 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 23 May 2022 10:38:43 GMT
Subject: RFR: 8279031: Add API note to ToolProvider about being
 reusable/reentrant [v2]
In-Reply-To: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
References: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
Message-ID: <214conRfJyAdFNoHUsm_E8J_59VqLFYXvm6Z4PuYDrM=.67516d8e-5a7f-4871-97e9-4844374405a4@github.com>

> This commit adds an  API note to ToolProvider about being reusable/reentrant.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/spi/ToolProvider.java
  
  Co-authored-by: Anthony Vanelverdinghe <dev at anthonyv.be>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8833/files
  - new: https://git.openjdk.java.net/jdk/pull/8833/files/035c1b14..dd3c6b6a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8833&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8833&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8833.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8833/head:pull/8833

PR: https://git.openjdk.java.net/jdk/pull/8833

From duke at openjdk.java.net  Mon May 23 10:38:44 2022
From: duke at openjdk.java.net (Anthony Vanelverdinghe)
Date: Mon, 23 May 2022 10:38:44 GMT
Subject: RFR: 8279031: Add API note to ToolProvider about being
 reusable/reentrant [v2]
In-Reply-To: <214conRfJyAdFNoHUsm_E8J_59VqLFYXvm6Z4PuYDrM=.67516d8e-5a7f-4871-97e9-4844374405a4@github.com>
References: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
 <214conRfJyAdFNoHUsm_E8J_59VqLFYXvm6Z4PuYDrM=.67516d8e-5a7f-4871-97e9-4844374405a4@github.com>
Message-ID: <Tn_d3KCfq6Pxhh_JpEIGCNovLAC4ObMrDwn0YtWFdV8=.f6763870-63f5-4616-a0f7-297f37a11130@github.com>

On Mon, 23 May 2022 10:34:51 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This commit adds an  API note to ToolProvider about being reusable/reentrant.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/spi/ToolProvider.java
>   
>   Co-authored-by: Anthony Vanelverdinghe <dev at anthonyv.be>

src/java.base/share/classes/java/util/spi/ToolProvider.java line 57:

> 55:  * reusable and reentrant, or should clearly document any limitations and
> 56:  * restrictions. In this context, reusable means that any one instance of
> 57:  * a tool may be a the target of multiple {@code run} method invocations,

Suggestion:

 * a tool may be the target of multiple {@code run} method invocations,

-------------

PR: https://git.openjdk.java.net/jdk/pull/8833

From cstein at openjdk.java.net  Mon May 23 10:38:44 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 23 May 2022 10:38:44 GMT
Subject: RFR: 8279031: Add API note to ToolProvider about being
 reusable/reentrant [v2]
In-Reply-To: <Tn_d3KCfq6Pxhh_JpEIGCNovLAC4ObMrDwn0YtWFdV8=.f6763870-63f5-4616-a0f7-297f37a11130@github.com>
References: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
 <214conRfJyAdFNoHUsm_E8J_59VqLFYXvm6Z4PuYDrM=.67516d8e-5a7f-4871-97e9-4844374405a4@github.com>
 <Tn_d3KCfq6Pxhh_JpEIGCNovLAC4ObMrDwn0YtWFdV8=.f6763870-63f5-4616-a0f7-297f37a11130@github.com>
Message-ID: <Z9dlg72w0gVEcLcoIu9yfYqm2nyd96i-lszPRkwKjFQ=.34ab1d97-fbdb-4b53-b4c9-8141d60a67c3@github.com>

On Mon, 23 May 2022 10:32:09 GMT, Anthony Vanelverdinghe <duke at openjdk.java.net> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/util/spi/ToolProvider.java
>>   
>>   Co-authored-by: Anthony Vanelverdinghe <dev at anthonyv.be>
>
> src/java.base/share/classes/java/util/spi/ToolProvider.java line 57:
> 
>> 55:  * reusable and reentrant, or should clearly document any limitations and
>> 56:  * restrictions. In this context, reusable means that any one instance of
>> 57:  * a tool may be a the target of multiple {@code run} method invocations,
> 
> Suggestion:
> 
>  * a tool may be the target of multiple {@code run} method invocations,

Thank you, Anthony.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8833

From asotona at openjdk.java.net  Mon May 23 10:40:40 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 10:40:40 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v9]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <W_1U5L9wg5OtyL_Ar1-3297-G3AA7DQKexeRB1qm6D8=.cf6451b5-559d-4d20-b3d6-b294f5b1cf06@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   re-enabled warnings for java.base, java.rmi and java.smartcardio
 - Merge branch 'openjdk:master' into JDK-8244681
 - lossy conversions addressed in java.net.http, jdk.incubator.foreign, Microbenchmarks and most of java.base
   new case appeared in java.base by moving jdk.incubator.foreign code under java.base
 - Merge remote-tracking branch 'upstream/master' into JDK-8244681
   
   # Conflicts:
   #	make/test/BuildMicrobenchmark.gmk
 - enabled lossy-conversions warnings for jdk.jfr and jdk.management.jfr
 - Merge branch 'openjdk:master' into JDK-8244681
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning description
 - 8244681: Add a warning for possibly lossy conversion in compound assignments
   recommended correction of the warning wording
   fixed typo in test method name
 - Merge branch 'openjdk:master' into JDK-8244681
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c9065915...455720ef

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08
  Stats: 441 lines in 18 files changed: 438 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From asotona at openjdk.java.net  Mon May 23 11:02:32 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Mon, 23 May 2022 11:02:32 GMT
Subject: RFR: 8244681: Add a warning for possibly lossy conversion in
 compound assignments [v10]
In-Reply-To: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
References: <80Nc7RlktP0cIEF2KjiCJbdCCg91jrOpT93uTQ7Hn-8=.75c5d4a4-d165-4ab8-941c-0fb5f6e6aa44@github.com>
Message-ID: <BjXRwHICfpOB1Ol2lbijomFjPYp0eaUL2Y2NRkHYuRQ=.346a7ec5-96ed-48a3-9c36-af1aea010a8e@github.com>

> Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions.
> 
> The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable.
> 
> The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. 
> 
> Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments.
> 
> Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks.
> 
> Thanks for your review,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - re-enabled lossy-conversion javac warnings in JDK Build Tools and jdk.compiler module
 - Added man-page line about lossy-conversion lint

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8599/files
  - new: https://git.openjdk.java.net/jdk/pull/8599/files/455720ef..4978c2a6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=08-09

  Stats: 5 lines in 3 files changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8599.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599

PR: https://git.openjdk.java.net/jdk/pull/8599

From alanb at openjdk.java.net  Mon May 23 11:13:31 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 11:13:31 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
Message-ID: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>

This is the implementation of JEP 428: Structured Concurrency (Incubator).

This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

-------------

Commit messages:
 - @ignore StructuredThreadDumpTest until test infra in place
 - Refresh
 - Merge
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/8787/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8787&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284199
  Stats: 2801 lines in 10 files changed: 2800 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8787/head:pull/8787

PR: https://git.openjdk.java.net/jdk/pull/8787

From duke at openjdk.java.net  Mon May 23 11:13:32 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Mon, 23 May 2022 11:13:32 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
In-Reply-To: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
Message-ID: <WGd5nmSWBBbiBrJjd11phIpQTul6ieBymt6WoerbRSE=.389efca6-4df0-42ca-ad51-0f075185ae63@github.com>

On Thu, 19 May 2022 13:05:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 428: Structured Concurrency (Incubator).
> 
> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 1172:

> 1170:                 }
> 1171:             };
> 1172:             return AccessController.doPrivileged(pa);

It?might be?better to?use `MethodHandle`s obtained?using <code>[jdk.internal.access.SharedSecrets]&#x200B;.getJavaLangInvokeAccess()</code> and?<code>[JavaLangInvokeAccess]&#x200B;.findStatic(?)</code> and?<code>[JavaLangInvokeAccess]&#x200B;.findVirtual(?)</code> for?this, which?would?avoid going?through `AccessController.doPrivilaged(?)`.

[jdk.internal.access.SharedSecrets]: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java
[JavaLangInvokeAccess]: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From alanb at openjdk.java.net  Mon May 23 11:13:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 11:13:32 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
In-Reply-To: <WGd5nmSWBBbiBrJjd11phIpQTul6ieBymt6WoerbRSE=.389efca6-4df0-42ca-ad51-0f075185ae63@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <WGd5nmSWBBbiBrJjd11phIpQTul6ieBymt6WoerbRSE=.389efca6-4df0-42ca-ad51-0f075185ae63@github.com>
Message-ID: <wK31aaJdeRpSFdIk2en-CRRVAhlJD12r9vndMPE8iBw=.7c46ab17-1bf9-43c8-842d-f97af31189ae@github.com>

On Sat, 21 May 2022 14:09:59 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>> 
>> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 1172:
> 
>> 1170:                 }
>> 1171:             };
>> 1172:             return AccessController.doPrivileged(pa);
> 
> It?might be?better to?use `MethodHandle`s obtained?using <code>[jdk.internal.access.SharedSecrets]&#x200B;.getJavaLangInvokeAccess()</code> and?<code>[JavaLangInvokeAccess]&#x200B;.findStatic(?)</code> and?<code>[JavaLangInvokeAccess]&#x200B;.findVirtual(?)</code> for?this, which?would?avoid going?through `AccessController.doPrivilaged(?)`.
> 
> [jdk.internal.access.SharedSecrets]: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java
> [JavaLangInvokeAccess]: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java

I'd prefer not export jdk.internal.access to this module, if possible.  In general, it's a lot easier to reason about the security and integrity of the core platform when java.base doesn't export any of its internal packages.

In any case, I expect this issue will resolve itself once there is a way for code in "core" modules to use preview APIs without needing to be compiled with --enable-preview. The java.management and jdk.incubator.vector modules have the same issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From zgu at openjdk.java.net  Mon May 23 12:45:32 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 23 May 2022 12:45:32 GMT
Subject: RFR: 8286956: Loom: Define test groups for development/porting use
In-Reply-To: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
References: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
Message-ID: <7CXFt1mPrcAvaizJvSxqzEnQfMTGZrH2n6w3_JjEC44=.ae250594-6438-4e84-9d02-21f160d5f560@github.com>

On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work.
> 
> https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
> https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125
> 
> I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom`
>  - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom`

This will help fixing the breakage of Shenandoah + Loom.

-------------

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8765

From brian.goetz at oracle.com  Mon May 23 12:53:27 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 23 May 2022 08:53:27 -0400
Subject: <T> Stream.fromForEach(Consumer<Consumer<T>>)
In-Reply-To: <1144676012.11391840.1653173645995.JavaMail.zimbra@u-pem.fr>
References: <1144676012.11391840.1653173645995.JavaMail.zimbra@u-pem.fr>
Message-ID: <52b1e6c5-ca0c-39ea-59ca-aa341f81bd4a@oracle.com>

This is a nice use of `mapMulti` to create a stream whose contents are 
dynamically generated.? It is one step short of generators (which we 
hope Loom will eventually give us), in that it is restricted to a 
generator method that generates all of the elements in one invocation.? 
This is still quite expressive.? (In hindsight, the name `generate` was 
wasted on the current `Stream::generate`, which is not all that useful 
and taking up a good name.)

I agree that the naming needs work, and people may well need help 
navigating the type `Consumer<Consumer<T>>`. Push is evocative, but 
there's more than just push; it's more like you have to kick something 
into pushing.? (Perhaps it is like the mythical Pushmi-Pullyu beast.)

Ideally, what is captured in the naming is that the outer `consumer` 
method is called exactly once, and that it should call the inner 
consumer to push elements.? (Of course that's a lot to capture.)? 
Something that evokes "build by push", perhaps.? Stream::fromPush is 
about the best I've got right now.

Are there any useful Consumer<Consumer<T>> in the wild, that are 
actually typed like that?? I doubt it (there are many things convertible 
to it, though.)? Which suggests it might be fruitful to define a FI:

 ??? interface PushSource<T> {
 ??????? void accept(Consumer<? extends Consumer<T>> pusher);
 ??? }

 ??? static<T> Stream<T> fromPush(PushSource<T> source) { ... }

and Iterable::forEachRemaining and Optional::ifPresent will convert to it.


On 5/21/2022 6:54 PM, Remi Forax wrote:
> Hi all,
> a stream is kind of push iterator so it can be created from any object that has a method like forEach(Consumer),
> but sadly there is no static method to create a Stream from a Consumer of Consumer so people usually miss that creating a Stream from events pushed to a consumer is easy.
>
> By example, let say i've a very simple parser like this, it calls the listener/callback for each tokens
>
>    record Parser(String text) {
>      void parse(Consumer<? super String> listener) {
>        for(var token: text.split(" ")) {
>           listener.accept(token);
>        }
>      }
>    }
>
> Using the method Stream.fromForEach, we can create a Stream from the sequence of tokens that are pushed through the listener
>    var parser = new Parser("1 2");
>    var stream = Stream.fromForEach(parser::parse);
>
> It can also works with an iterable, an optional or even a collection
>    Iterable<String> iterable = ...
>    var stream = Stream.fromForEach(iterable::forEachRemaning);
>
>    Optional<String> optional = ...
>    var stream = Stream.fromForEach(optional::ifPresent);
>
>    List<String> list = ...
>    var stream = Stream.fromForEach(list::forEach);
>
> I known the last two examples already have their own method stream(), it's just to explain how Stream.fromForEach is supposed to work.
>
> In term of implementation, Stream.fromForEach() is equivalent to creating a stream using a mapMulti(), so it can be implemented like this
>
>    static <T> Stream<T> fromForEach(Consumer<? super Consumer<T>> forEach) {
>      return Stream.of((T) null).mapMulti((__, consumer) -> forEach.accept(consumer));
>    }
>
> but i think that Stream.fromForEach(iterable::forEachRemaning) is more readable than Stream.of(iterable).mapMult(Iterable::forEachRemaining).
>
> The name fromForEach is not great and i'm sure someone will come with a better one.
>
> regards,
> R?mi

From dfuchs at openjdk.java.net  Mon May 23 13:14:36 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 23 May 2022 13:14:36 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
In-Reply-To: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
Message-ID: <nkRgejFGcz9Cx5U5dDTUjbaS24sVO6OUkafoJD9vzq4=.0600993b-e758-4064-8449-cabd0e6127ad@github.com>

On Thu, 19 May 2022 13:05:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 428: Structured Concurrency (Incubator).
> 
> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 54:

> 52: 
> 53: /**
> 54:  * A basic API for <em>structured concurrency</em>. StructuredTaskScope supports cases

Should StructuredTaskScope in this class-level API doc comment be surrounded by `{@code }` to appear in code font?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From jvernee at openjdk.java.net  Mon May 23 13:28:30 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 May 2022 13:28:30 GMT
Subject: RFR: 8287158: Explicitly reject unsupported call shapes on
 macos-aarch64 in mainline
Message-ID: <jzT8uoRxxN4ZEXD-3aFO2eLIJJYSVpw3R_gYQNls9GM=.95b5ec65-9aad-42f9-894f-598e70ad449f@github.com>

Bring in changes from the panama-foreign repo

These changes pertain to explicitly rejecting unsupported call shapes on macos-aarch64.

Testing: `jdk_foreign` on linux-aarch64-debug, macosx-aarch64-debug, linux-x64-debug, macosx-x64-debug, and windows-x64-debug

-------------

Commit messages:
 - Fix copyright year for new file
 - Fix tests
 - 8284306: TestVarArgs silently passes
 - 8284041: Explicitly reject unsupported call shapes on macos-aarch64

Changes: https://git.openjdk.java.net/jdk/pull/8842/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8842&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287158
  Stats: 25411 lines in 18 files changed: 719 ins; 24633 del; 59 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8842.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8842/head:pull/8842

PR: https://git.openjdk.java.net/jdk/pull/8842

From jvernee at openjdk.java.net  Mon May 23 13:28:31 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 May 2022 13:28:31 GMT
Subject: RFR: 8287158: Explicitly reject unsupported call shapes on
 macos-aarch64 in mainline
In-Reply-To: <jzT8uoRxxN4ZEXD-3aFO2eLIJJYSVpw3R_gYQNls9GM=.95b5ec65-9aad-42f9-894f-598e70ad449f@github.com>
References: <jzT8uoRxxN4ZEXD-3aFO2eLIJJYSVpw3R_gYQNls9GM=.95b5ec65-9aad-42f9-894f-598e70ad449f@github.com>
Message-ID: <HIVhsXAy3V2AGokSpVykBnW8jfGIicJextj6O6SGlf8=.76a8488f-2cfa-4fd6-9d0c-7271c30b57c7@github.com>

On Mon, 23 May 2022 12:27:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Bring in changes from the panama-foreign repo
> 
> These changes pertain to explicitly rejecting unsupported call shapes on macos-aarch64.
> 
> Testing: `jdk_foreign` on linux-aarch64-debug, macosx-aarch64-debug, linux-x64-debug, macosx-x64-debug, and windows-x64-debug

test/jdk/java/foreign/shared.h line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2022, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8842

From duke at openjdk.java.net  Mon May 23 14:25:49 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 23 May 2022 14:25:49 GMT
Subject: RFR: 8284493: Fix rounding error in computeNextExponential
In-Reply-To: <GMGWQhNckhBCqioWrC4enqwuc-_w7QF349mOOcWNvzA=.c0e52085-98be-4401-8e13-2cb71536c0fa@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <GMGWQhNckhBCqioWrC4enqwuc-_w7QF349mOOcWNvzA=.c0e52085-98be-4401-8e13-2cb71536c0fa@github.com>
Message-ID: <nm1EHY6w6N2bcs7q8MylQmAg169c5jupAUbu6kVaZuc=.376dd38b-4f8c-447e-a079-06fa03b2b414@github.com>

On Sun, 22 May 2022 20:19:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around 2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1); this fixes that by tracking the multiple of exponentialX0 as a long. (This changes the maximum possible output to `1.0p63 * DoubleZigguratTables.exponentialX0 == 0x1.e46eff20739afp65`; previously it would have been `0x1.0p56` because once `extra` reaches that amount, `x + extra == extra` due to the rounding error. This lowers the probability of reaching the maximum with an ideal PRNG from about `1.3877787807814488E-17` to about `1.4323726067488646E-20` (calculated using the identity `ln(x) == Math.log10(x)/Math.log10(Math.exp(1))`).
>
> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1411:
> 
>> 1409:                 long U2 = (rng.nextLong() >>> 1);
>> 1410:                 // Compute the actual x-coordinate of the randomly chosen point.
>> 1411:                 x = Math.fma(X[j-1] - X[j], (double)U1, X[j] * 0x1.0p63));
> 
> Code is not compilable

@Pr0methean As @turbanoff observes, I think there's a closing parentheses too much on L.1411 and one on L.1421.
Which compiler are you using ;-)  ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8131

From shade at openjdk.java.net  Mon May 23 15:13:05 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 15:13:05 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration
Message-ID: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>

[JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.

Additional testing:
 - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
 - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
 - [x] Linux x86_32 fastdebug `tier3` (clean now)
 - [ ] GHA run

-------------

Commit messages:
 - Updates
 - Revert test groups
 - Fix 2
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/8843/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287137
  Stats: 276 lines in 3 files changed: 276 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8843/head:pull/8843

PR: https://git.openjdk.java.net/jdk/pull/8843

From alanb at openjdk.java.net  Mon May 23 15:15:09 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 15:15:09 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
Message-ID: <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>

On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>  - [ ] GHA run

test/jdk/ProblemList.txt line 894:

> 892: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java  8286642 generic-i586
> 893: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorExample.java          8286642 generic-i586
> 894: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java  8286642 generic-i586

I'm surprised that the stream tests are included as they don't run with --enable-preview.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From shade at openjdk.java.net  Mon May 23 15:21:41 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 15:21:41 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>
Message-ID: <JrPM8mw-PX8nyS5WHrP9aVyL5NJhaswOwGuodIZuLpA=.2b7a0996-9c4f-4f3b-a521-b9dfd23aea55@github.com>

On Mon, 23 May 2022 15:13:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>>  - [ ] GHA run
>
> test/jdk/ProblemList.txt line 894:
> 
>> 892: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java  8286642 generic-i586
>> 893: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorExample.java          8286642 generic-i586
>> 894: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java  8286642 generic-i586
> 
> I'm surprised that the stream tests are included as they don't run with --enable-preview.

Those tests *do* run with preview enabled: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/stream/test/TEST.properties#L10-L11 -- and I know that because I basically copy-pasted all jtreg failures that lead to `Unimplemented()` in x86_32 code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From prr at openjdk.java.net  Mon May 23 15:28:56 2022
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 23 May 2022 15:28:56 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
Message-ID: <ZxzsiPHBQGnGxXkuOz4eYvoGkjhwizLhmwFLUUZidlE=.8cb8d8d2-40b3-4dc7-9511-f6c0e5e88af2@github.com>

On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>  - [ ] GHA run

I agree this is better than disabling the entire GHA

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8843

From alanb at openjdk.java.net  Mon May 23 15:39:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 23 May 2022 15:39:40 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <JrPM8mw-PX8nyS5WHrP9aVyL5NJhaswOwGuodIZuLpA=.2b7a0996-9c4f-4f3b-a521-b9dfd23aea55@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>
 <JrPM8mw-PX8nyS5WHrP9aVyL5NJhaswOwGuodIZuLpA=.2b7a0996-9c4f-4f3b-a521-b9dfd23aea55@github.com>
Message-ID: <j6KHk-lOPx98mqZVOA9lXXuEtTuIfK1N3M3afPC2qs8=.9b0ccab0-c3ba-4866-9d47-5812316be121@github.com>

On Mon, 23 May 2022 15:18:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/jdk/ProblemList.txt line 894:
>> 
>>> 892: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java  8286642 generic-i586
>>> 893: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorExample.java          8286642 generic-i586
>>> 894: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java  8286642 generic-i586
>> 
>> I'm surprised that the stream tests are included as they don't run with --enable-preview.
>
> Those tests *do* run with preview enabled: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/stream/test/TEST.properties#L10-L11 -- and I know that because I basically copy-pasted all jtreg failures that lead to `Unimplemented()` in x86_32 code.

Okay, so the issue is SpliteratorTest uses preview APIs and having the configuration in TEST.properties means that all the streams tests are run with this option.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From shade at openjdk.java.net  Mon May 23 15:39:40 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 15:39:40 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <j6KHk-lOPx98mqZVOA9lXXuEtTuIfK1N3M3afPC2qs8=.9b0ccab0-c3ba-4866-9d47-5812316be121@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>
 <JrPM8mw-PX8nyS5WHrP9aVyL5NJhaswOwGuodIZuLpA=.2b7a0996-9c4f-4f3b-a521-b9dfd23aea55@github.com>
 <j6KHk-lOPx98mqZVOA9lXXuEtTuIfK1N3M3afPC2qs8=.9b0ccab0-c3ba-4866-9d47-5812316be121@github.com>
Message-ID: <a8vijo-jBGq72_Ub_hdAjQUhKVMAIzF4uV29CNQbIZo=.0a52e702-e95b-409f-86d7-8b980a3351e3@github.com>

On Mon, 23 May 2022 15:34:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Those tests *do* run with preview enabled: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/stream/test/TEST.properties#L10-L11 -- and I know that because I basically copy-pasted all jtreg failures that lead to `Unimplemented()` in x86_32 code.
>
> Okay, so the issue is SpliteratorTest uses preview APIs and having the configuration in TEST.properties means that all the streams tests are run with this option.

Yes, `TEST.properties` is way too broad. I'd keep the current patch as is, instead of trying to fix that one. I suspect there is some funky TestNG/othervm interaction going...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From shade at openjdk.java.net  Mon May 23 16:18:36 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 16:18:36 GMT
Subject: RFR: 8286956: Loom: Define test groups for development/porting use
In-Reply-To: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
References: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
Message-ID: <HtWr3MncmySZIgEDE9HDF6mggMHYARNS0_LyjZzUl1s=.524779bf-a45e-447b-9c66-2763bc3c4a57@github.com>

On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work.
> 
> https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
> https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125
> 
> I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom`
>  - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom`

All right, thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8765

From shade at openjdk.java.net  Mon May 23 16:20:50 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 16:20:50 GMT
Subject: Integrated: 8286956: Loom: Define test groups for development/porting
 use
In-Reply-To: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
References: <RS6I_eEwnrpxpMxbkyGxT6sLKkaBCm9zWAf9Ft2NBTQ=.936a5b13-88ea-4063-b6db-f50abe12d85b@github.com>
Message-ID: <hDp84lm8R9hb1TB2ko2KqrNNk2aJRY7FOK8G12gjNew=.e0521313-51be-4f59-aad6-f4be7f9908ba@github.com>

On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work.
> 
> https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108
> https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125
> 
> I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom`
>  - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom`

This pull request has now been integrated.

Changeset: ac274c4c
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ac274c4ca67555742065dc850823e924361f2ff7
Stats:     28 lines in 2 files changed: 28 ins; 0 del; 0 mod

8286956: Loom: Define test groups for development/porting use

Reviewed-by: alanb, zgu

-------------

PR: https://git.openjdk.java.net/jdk/pull/8765

From naoto at openjdk.java.net  Mon May 23 16:25:03 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 May 2022 16:25:03 GMT
Subject: Integrated: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate
In-Reply-To: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
References: <say6mMDUOOv-IQTvLHni19D2OP6BlZ24dR9DKgPeX78=.a25e6d0f-e026-4ee7-bf8b-0e5421812e2d@github.com>
Message-ID: <NKSat1xWtvvQ-p6PnOgKTNi6z5rJReb1dR4zr67rYt0=.92d59edb-5016-4083-a11c-22383a6254c1@github.com>

On Thu, 3 Mar 2022 19:33:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: ef7a9f81
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ef7a9f817096d5fac8ed624cadb087fcbe5eb98a
Stats:     282 lines in 13 files changed: 244 ins; 10 del; 28 mod

8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate

Reviewed-by: joehw, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/7683

From jbhateja at openjdk.java.net  Mon May 23 16:28:23 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 23 May 2022 16:28:23 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v3]
In-Reply-To: <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com>
 <iHjm0MtVszGRhw-3afZQUc82rguV5LG9qxo2l-18Opw=.08d1c28f-00d3-4e61-836f-f02a08931504@github.com>
Message-ID: <UMg-ylyxEjvpCzDPny3_Z5dRmCoT_7IDAUc1NYxXG_k=.7b83fc73-bb98-4ac8-96d3-9fc5bcfa74a9@github.com>

On Thu, 12 May 2022 23:56:49 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - 8284960: Correcting a typo.
>>  - 8284960: Integrating changes from panama-vector (Add @since 19 tags).
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - 8284960: AARCH64 backend changes.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...b021e082
>
> Overall, looks good.
> 
> Some minor questions/suggestions follow.

Hi @iwanowww , your comments have been addressed. kindly let me know if you have other comments on x86 side changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From mcimadamore at openjdk.java.net  Mon May 23 16:45:58 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 May 2022 16:45:58 GMT
Subject: RFR: 8287158: Explicitly reject unsupported call shapes on
 macos-aarch64 in mainline
In-Reply-To: <jzT8uoRxxN4ZEXD-3aFO2eLIJJYSVpw3R_gYQNls9GM=.95b5ec65-9aad-42f9-894f-598e70ad449f@github.com>
References: <jzT8uoRxxN4ZEXD-3aFO2eLIJJYSVpw3R_gYQNls9GM=.95b5ec65-9aad-42f9-894f-598e70ad449f@github.com>
Message-ID: <zlsFG8BLQ-uieZ3MFqtjfSSMU_Ganxto6zvjqh9uYZ4=.949981d8-6fc5-4d90-b56d-a99d24f930d7@github.com>

On Mon, 23 May 2022 12:27:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Bring in changes from the panama-foreign repo
> 
> These changes pertain to explicitly rejecting unsupported call shapes on macos-aarch64.
> 
> Original PRs:
> 1. https://github.com/openjdk/panama-foreign/pull/676
> 2. https://github.com/openjdk/panama-foreign/pull/677
> 
> Testing: `jdk_foreign` on linux-aarch64-debug, macosx-aarch64-debug, linux-x64-debug, macosx-x64-debug, and windows-x64-debug

Looks good!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8842

From mcimadamore at openjdk.java.net  Mon May 23 16:50:50 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 May 2022 16:50:50 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <a8vijo-jBGq72_Ub_hdAjQUhKVMAIzF4uV29CNQbIZo=.0a52e702-e95b-409f-86d7-8b980a3351e3@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <TSOFvezGyuJH9c2GlK-cA2Pie0Hd6kzvm5_XEP0pqSI=.f436a2fc-a865-4a55-b459-cd864d5cc5cc@github.com>
 <JrPM8mw-PX8nyS5WHrP9aVyL5NJhaswOwGuodIZuLpA=.2b7a0996-9c4f-4f3b-a521-b9dfd23aea55@github.com>
 <j6KHk-lOPx98mqZVOA9lXXuEtTuIfK1N3M3afPC2qs8=.9b0ccab0-c3ba-4866-9d47-5812316be121@github.com>
 <a8vijo-jBGq72_Ub_hdAjQUhKVMAIzF4uV29CNQbIZo=.0a52e702-e95b-409f-86d7-8b980a3351e3@github.com>
Message-ID: <HxvJ78fLsFmgrtMkO8FS3Kc-QWvnR6_WNMtTdYum6Nw=.f5d754f0-6800-478d-8f13-2fdd419d558c@github.com>

On Mon, 23 May 2022 15:36:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Okay, so the issue is SpliteratorTest uses preview APIs and having the configuration in TEST.properties means that all the streams tests are run with this option.
>
> Yes, `TEST.properties` is way too broad. I'd keep the current patch as is, instead of trying to fix that one. I suspect there is some funky TestNG/othervm interaction going...

These specific stream tests are odd, in the sense that they live in a test root that is TestNG and they are only "imported" into jtreg. The toplevel TEST.properties file gets only once chance to set the correct parameters, for all tests. I've tried adding more local flags, nearer to the test, w/o success. I'm obviously happy to do it another way.

I have tried adding a jtreg header in that test, but that doesn't fix the problem - because _all_ the tests are passed to testng at once, which compiles them and runs them. So either the flag is present when that happens, or it is ignored.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From darcy at openjdk.java.net  Mon May 23 17:04:49 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 23 May 2022 17:04:49 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v3]
In-Reply-To: <8wSTD-EmbxMEVwd9hPfLPCudwb-Rrj-tTt80F9o1Npc=.8146bcf1-31ce-4322-afd1-f26591ff48f4@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <8wSTD-EmbxMEVwd9hPfLPCudwb-Rrj-tTt80F9o1Npc=.8146bcf1-31ce-4322-afd1-f26591ff48f4@github.com>
Message-ID: <vivPyQS6DGqbrjkT45A66xTg5UJhBpYZmafEiyf9l3s=.bcc43fd9-0633-42a2-b534-44b3303115dc@github.com>

On Tue, 10 May 2022 13:47:35 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Add a family of "safe" cast methods.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279986: methods Math::asXExact for safely checked primitive casts

As a reminder, once the spec is finalized, versions of the methods and spec need to be added to StrictMath too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8548

From shade at openjdk.java.net  Mon May 23 17:16:28 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 17:16:28 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v2]
In-Reply-To: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
Message-ID: <t9frIICDowzgXUtOZMbKamViP3qgG9D_cLOVpWWmumI=.1ebc7b02-65eb-46b1-851b-f7ae1a30681e@github.com>

> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>  - [ ] GHA run

Aleksey Shipilev 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 six additional commits since the last revision:

 - Fix the tests in release JDKs
 - Merge branch 'master' into JDK-8287137-problemlist-x86_32
 - Updates
 - Revert test groups
 - Fix 2
 - Fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8843/files
  - new: https://git.openjdk.java.net/jdk/pull/8843/files/ba5c631e..5a0cd8fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=00-01

  Stats: 4568 lines in 145 files changed: 2586 ins; 1656 del; 326 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8843/head:pull/8843

PR: https://git.openjdk.java.net/jdk/pull/8843

From stevenschlansker at gmail.com  Mon May 23 17:36:23 2022
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Mon, 23 May 2022 10:36:23 -0700
Subject: <T> Stream.fromForEach(Consumer<Consumer<T>>)
In-Reply-To: <52b1e6c5-ca0c-39ea-59ca-aa341f81bd4a@oracle.com>
References: <1144676012.11391840.1653173645995.JavaMail.zimbra@u-pem.fr>
 <52b1e6c5-ca0c-39ea-59ca-aa341f81bd4a@oracle.com>
Message-ID: <81DD4A3E-F240-4719-825E-12C33CF0F15C@gmail.com>



> On May 23, 2022, at 5:53 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> This is a nice use of `mapMulti` to create a stream whose contents are dynamically generated.  It is one step short of generators (which we hope Loom will eventually give us), in that it is restricted to a generator method that generates all of the elements in one invocation.  This is still quite expressive.  (In hindsight, the name `generate` was wasted on the current `Stream::generate`, which is not all that useful and taking up a good name.)
> 
> I agree that the naming needs work, and people may well need help navigating the type `Consumer<Consumer<T>>`. Push is evocative, but there's more than just push; it's more like you have to kick something into pushing.  (Perhaps it is like the mythical Pushmi-Pullyu beast.)
> 
> Ideally, what is captured in the naming is that the outer `consumer` method is called exactly once, and that it should call the inner consumer to push elements.  (Of course that's a lot to capture.)  Something that evokes "build by push", perhaps.  Stream::fromPush is about the best I've got right now.
> 
> Are there any useful Consumer<Consumer<T>> in the wild, that are actually typed like that?  I doubt it (there are many things convertible to it, though.)  Which suggests it might be fruitful to define a FI:

We have such a use case "in the wild" but for a slightly different purpose - instead of adapting to a Stream, it adapts to a JAX-RS StreamingOutput.

StreamingOutput ofItems(Consumer<? super Consumer<? super Object>> itemGenerator) { ... }

Wrapping the logic in this PushSource-like abstraction allows us to wrap the generated JSON stream with a header, footer, and to handle each item.
And, it seems that we might even have gotten the wildcard super vs extends wrong! If the standard library provided such a PushSource FI,
we would have used that, and avoided doing it possibly incorrectly ourselves.


>     interface PushSource<T> {
>         void accept(Consumer<? extends Consumer<T>> pusher);
>     }
> 
>     static<T> Stream<T> fromPush(PushSource<T> source) { ... }
> 
> and Iterable::forEachRemaining and Optional::ifPresent will convert to it.
> 
> 
> On 5/21/2022 6:54 PM, Remi Forax wrote:
>> Hi all,
>> a stream is kind of push iterator so it can be created from any object that has a method like forEach(Consumer),
>> but sadly there is no static method to create a Stream from a Consumer of Consumer so people usually miss that creating a Stream from events pushed to a consumer is easy.
>> 
>> By example, let say i've a very simple parser like this, it calls the listener/callback for each tokens
>> 
>>   record Parser(String text) {
>>     void parse(Consumer<? super String> listener) {
>>       for(var token: text.split(" ")) {
>>          listener.accept(token);
>>       }
>>     }
>>   }
>> 
>> Using the method Stream.fromForEach, we can create a Stream from the sequence of tokens that are pushed through the listener
>>   var parser = new Parser("1 2");
>>   var stream = Stream.fromForEach(parser::parse);
>> 
>> It can also works with an iterable, an optional or even a collection
>>   Iterable<String> iterable = ...
>>   var stream = Stream.fromForEach(iterable::forEachRemaning);
>> 
>>   Optional<String> optional = ...
>>   var stream = Stream.fromForEach(optional::ifPresent);
>> 
>>   List<String> list = ...
>>   var stream = Stream.fromForEach(list::forEach);
>> 
>> I known the last two examples already have their own method stream(), it's just to explain how Stream.fromForEach is supposed to work.
>> 
>> In term of implementation, Stream.fromForEach() is equivalent to creating a stream using a mapMulti(), so it can be implemented like this
>> 
>>   static <T> Stream<T> fromForEach(Consumer<? super Consumer<T>> forEach) {
>>     return Stream.of((T) null).mapMulti((__, consumer) -> forEach.accept(consumer));
>>   }
>> 
>> but i think that Stream.fromForEach(iterable::forEachRemaning) is more readable than Stream.of(iterable).mapMult(Iterable::forEachRemaining).
>> 
>> The name fromForEach is not great and i'm sure someone will come with a better one.
>> 
>> regards,
>> R?mi


From shade at openjdk.java.net  Mon May 23 18:25:23 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 May 2022 18:25:23 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
Message-ID: <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>

> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>  - [ ] GHA run

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Another release test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8843/files
  - new: https://git.openjdk.java.net/jdk/pull/8843/files/5a0cd8fe..e223e211

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8843/head:pull/8843

PR: https://git.openjdk.java.net/jdk/pull/8843

From duke at openjdk.java.net  Mon May 23 18:37:26 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 23 May 2022 18:37:26 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v4]
In-Reply-To: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
Message-ID: <Ryu_bY3v1E9Tv-oS12VBJvtFfU0eD0xzodeGa3XNBqg=.827bb39e-b9de-42fa-9928-985db0e29e7a@github.com>

> Add a family of "safe" cast methods.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8279986: methods Math::asXExact for safely checked primitive casts

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8548/files
  - new: https://git.openjdk.java.net/jdk/pull/8548/files/5f0ff527..f629f5b3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8548&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8548&range=02-03

  Stats: 201 lines in 1 file changed: 196 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548

PR: https://git.openjdk.java.net/jdk/pull/8548

From rriggs at openjdk.java.net  Mon May 23 18:37:51 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 23 May 2022 18:37:51 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <VijngstCNgus5frNVxsXNltFrk6gkcjOv8iBYfcrVls=.bf4f6194-de7f-467b-b5c0-88316be89289@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com>
 <VijngstCNgus5frNVxsXNltFrk6gkcjOv8iBYfcrVls=.bf4f6194-de7f-467b-b5c0-88316be89289@github.com>
Message-ID: <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com>

On Tue, 10 May 2022 19:24:24 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 777:
>> 
>>> 775:         if (!printStackPropertiesSet && VM.initLevel() >= 1) {
>>> 776:             printStackWhenAccessFails = GetBooleanAction.
>>> 777:                 privilegedGetProperty("sun.reflect.debugModuleAccessChecks");
>> 
>> Running with `-Dsun.reflect.debugModuleAccessChecks` should set printStackWhenAccessFails to true, not false.
>
> You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes.

This change still needs to be reversed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8559

From duke at openjdk.java.net  Mon May 23 18:42:36 2022
From: duke at openjdk.java.net (kristylee88)
Date: Mon, 23 May 2022 18:42:36 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v4]
In-Reply-To: <Ryu_bY3v1E9Tv-oS12VBJvtFfU0eD0xzodeGa3XNBqg=.827bb39e-b9de-42fa-9928-985db0e29e7a@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <Ryu_bY3v1E9Tv-oS12VBJvtFfU0eD0xzodeGa3XNBqg=.827bb39e-b9de-42fa-9928-985db0e29e7a@github.com>
Message-ID: <gmM-6bW7LcNVV6u5u8pUmUW7Y69APLRNK-WV949YmKE=.1623b45c-e57e-4838-b91b-e873ef9da79e@github.com>

On Mon, 23 May 2022 18:37:26 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Add a family of "safe" cast methods.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279986: methods Math::asXExact for safely checked primitive casts

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8548

From duke at openjdk.java.net  Mon May 23 18:47:33 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 23 May 2022 18:47:33 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v5]
In-Reply-To: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
Message-ID: <St_hV6SU6MDtze26_v_UvbYhAyL1q5C0ybVwBtRV3Hw=.164dc1a5-d8bf-4f34-9fdf-0f5a85c9c7b2@github.com>

> Add a family of "safe" cast methods.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8279986: methods Math::asXExact for safely checked primitive casts

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8548/files
  - new: https://git.openjdk.java.net/jdk/pull/8548/files/f629f5b3..5fb1fed4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8548&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8548&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548

PR: https://git.openjdk.java.net/jdk/pull/8548

From duke at openjdk.java.net  Mon May 23 18:58:34 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Mon, 23 May 2022 18:58:34 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults [v2]
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>

> JDK-6725221 Standardize obtaining boolean properties with defaults

Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Alan and Jamil comments
 - Merge
 - reverse true.equals and false.equals changes
 - Merge
 - Merge
 - first iteration

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8559&range=01
  Stats: 9 lines in 3 files changed: 1 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8559/head:pull/8559

PR: https://git.openjdk.java.net/jdk/pull/8559

From duke at openjdk.java.net  Mon May 23 19:03:51 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Mon, 23 May 2022 19:03:51 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults [v2]
In-Reply-To: <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <2FDlNpC_fh8aSTlDoJSKzR2DD3EOR5CRPLCAeb4u6L4=.a451b7d6-06ed-4411-84d3-bb2801cbfa31@github.com>
 <VijngstCNgus5frNVxsXNltFrk6gkcjOv8iBYfcrVls=.bf4f6194-de7f-467b-b5c0-88316be89289@github.com>
 <6_CLgH6C3qE24sCkgD23wyfRgiSBgVTNZwFNKOFpFXI=.88e2c0c7-a2b9-4dcd-888a-2fe11e414d3f@github.com>
Message-ID: <Q225NlMNasd2tzak-lkkM5PQgU5fV8CS1zDtXo0xQb0=.ba339f01-ac2a-4821-9e35-4e1d8f26c6b5@github.com>

On Mon, 23 May 2022 18:34:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> You are right. The old way maps the null string to true, and the new way maps it to false. I did not notice that. At this point, I see no value in making the "true".equals and "false".equals changes. Too much can break. I'll reverse these changes.
>
> This change still needs to be reversed.

The change has been reversed.

We had an internal discussion about IntelliJ's unboxing recommendation, and decided to let unboxing be a matter of personal preference. Those changes have been reversed too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8559

From psandoz at openjdk.java.net  Mon May 23 19:03:51 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 23 May 2022 19:03:51 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
In-Reply-To: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
Message-ID: <S_OyIMn14TlC44PxnkOgAGd2kTjhv8bmNvPjpLpRYIk=.1430ed5f-5d27-460d-bdc6-347e77682eda@github.com>

On Thu, 19 May 2022 13:05:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 428: Structured Concurrency (Incubator).
> 
> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

Previously reviewed while in the loom repo.

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructureViolationException.java line 40:

> 38: 
> 39:     /**
> 40:      * Constructs an {@code StructureViolationException} with no detail message.

Suggestion:

     * Constructs a {@code StructureViolationException} with no detail message.

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructureViolationException.java line 47:

> 45: 
> 46:     /**
> 47:      * Constructs an {@code StructureViolationException} with the specified

Suggestion:

     * Constructs a {@code StructureViolationException} with the specified

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8787

From psandoz at openjdk.java.net  Mon May 23 19:03:54 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 23 May 2022 19:03:54 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
In-Reply-To: <wK31aaJdeRpSFdIk2en-CRRVAhlJD12r9vndMPE8iBw=.7c46ab17-1bf9-43c8-842d-f97af31189ae@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <WGd5nmSWBBbiBrJjd11phIpQTul6ieBymt6WoerbRSE=.389efca6-4df0-42ca-ad51-0f075185ae63@github.com>
 <wK31aaJdeRpSFdIk2en-CRRVAhlJD12r9vndMPE8iBw=.7c46ab17-1bf9-43c8-842d-f97af31189ae@github.com>
Message-ID: <S-uR5OzosQiug9pqpzkEY3Hj6yuxImDy1Kh2JzPWQlE=.4f038e9d-cbb4-4762-a00e-d7c3b6b621f9@github.com>

On Sat, 21 May 2022 16:25:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 1172:
>> 
>>> 1170:                 }
>>> 1171:             };
>>> 1172:             return AccessController.doPrivileged(pa);
>> 
>> It?might be?better to?use `MethodHandle`s obtained?using <code>[jdk.internal.access.SharedSecrets]&#x200B;.getJavaLangInvokeAccess()</code> and?<code>[JavaLangInvokeAccess]&#x200B;.findStatic(?)</code> and?<code>[JavaLangInvokeAccess]&#x200B;.findVirtual(?)</code> for?this, which?would?avoid going?through `AccessController.doPrivilaged(?)`.
>> 
>> [jdk.internal.access.SharedSecrets]: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/access/SharedSecrets.java
>> [JavaLangInvokeAccess]: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java
>
> I'd prefer not export jdk.internal.access to this module, if possible.  In general, it's a lot easier to reason about the security and integrity of the core platform when java.base doesn't export any of its internal packages.
> 
> In any case, I expect this issue will resolve itself once there is a way for code in "core" modules to use preview APIs without needing to be compiled with --enable-preview. The java.management and jdk.incubator.vector modules have the same issue.

Yes, we will add a more general internal for source that participate in preview APIs, and then the use of reflection can be removed. (The Vector API PR has a focused fix to the compiler, since it cannot use the reflection trick).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From sgehwolf at openjdk.java.net  Mon May 23 19:13:58 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 23 May 2022 19:13:58 GMT
Subject: RFR: 8286212: Cgroup v1 initialization causes NPE on some systems
 [v3]
In-Reply-To: <KPDr-0LR7sXWsSUW5w_0Qbuh-MXaddpNBO6s5Lsd8_U=.80b1eb53-c1f9-4e8a-8ac7-7f8b092008cc@github.com>
References: <pqUZH2ArAs3HzvROblncKitEBqbBLHVTUjgXvOzu3EQ=.7970acec-5eb8-4741-97d5-7d7d08f8a515@github.com>
 <6EJTmtCW0gnRRF6rQhE-uA2-l9Hz8q0CEOexDdFPtKs=.1bf44414-ffe9-4d4f-9105-eddd8f4130cf@github.com>
 <GoKVcR4bqdz6OZ3Gh_4lpahvlcoTH6mIInQLZ03uhZI=.3b26ac26-05b1-4636-804d-fc64d0bd39f6@github.com>
 <2f2ZR7-88OJ8ZbP91tnp1gZOVzTYDSf62bRuCIaIUgQ=.1bee4889-4091-4126-bfa6-89c0b37298c7@github.com>
 <bPoDNxABi63JebXkYflJ3FUR0IF8OieXLmwkwjIxmk8=.1651330e-59af-4f56-932e-08d37626dfe9@github.com>
 <fRitJVBN5BS8dbJ0VvMDkFZ65xpDJvhd5KlCKk5DhMI=.ca576f15-5b74-48d3-b46a-1432780ad016@github.com>
 <KPDr-0LR7sXWsSUW5w_0Qbuh-MXaddpNBO6s5Lsd8_U=.80b1eb53-c1f9-4e8a-8ac7-7f8b092008cc@github.com>
Message-ID: <3kqALUtVpso2x-3Pv41cTPRvjpXI7_88yFPfj-xmRNg=.143ff56d-ad5a-4ffb-8649-03f9447a9248@github.com>

On Mon, 23 May 2022 09:24:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Also, I think the current PR could produce the wrong answer, if systemd is indeed running inside the container, and we have:
>> 
>> 
>> "/user.slice/user-1000.slice/session-50.scope",    // root_path
>> "/user.slice/user-1000.slice/session-3.scope",     // cgroup_path
>> 
>> 
>> The PR gives /sys/fs/cgroup/memory/user.slice/user-1000.slice/, which specifies the overall memory limit for user-1000. However, the correct answer may be /sys/fs/cgroup/memory/user.slice/user-1000.slice/session-3.scope, which may have a smaller memory limit, and the JVM may end up allocating a larger heap than allowed.
>
> Yes, if we can decide which one the right file is. This is largely undocumented territory. The correct fix is a) find the correct path to the namespace hierarchy the process is a part of. b) starting at the leaf node, walk up the hierarchy and find the **lowest** limits. Doing this would be very expensive!
> 
> Aside: Current container detection in the JVM/JDK is notoriously imprecise. It's largely based on common setups (containers like docker). The heuristics assume that memory limits are reported inside the container at the leaf node. If, however, that's not the case, the detected limits will be wrong (it will detect it as unlimited, even though it's - for example - memory constrained at the parent). This can for example be reproduced on a cgroups v2 system with a systemd slice using memory limits. We've worked-around this in OpenJDK for cgroups v1 by https://bugs.openjdk.java.net/browse/JDK-8217338

> Maybe we should do this instead?
> 
>     * Read /proc/self/cgroup
> 
>     * Find the `10:memory:<path>` line
> 
>     * If `/sys/fs/cgroup/memory/<path>/tasks` contains my PID, this is the path
> 
>     * Otherwise, scan all `tasks` files under  `/sys/fs/cgroup/memory/`. Exactly one of them contains my PID.

Something like that seems most promising, but it would have to be `cgroup.procs` not `tasks` as `tasks` is the task id (i.e. Linux's thread), not the process. We could keep the two common cases as short circuiting. I.e. host and docker cases in the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8629

From lancea at openjdk.java.net  Mon May 23 19:54:58 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 23 May 2022 19:54:58 GMT
Subject: RFR: 8287162: (zipfs) Performance regression related to support for
 POSIX file permissions
Message-ID: <znseZkEwQfyr0ih8UtE3cxNsXelAnN2pULr5Tj-oq6o=.35ca3a29-097b-4d1a-a3ff-52a5ca83c2c1@github.com>

Hi all,

This PR addresses the performance issue that is described in JDK-8287162.

With this fix,  the ZipFileSystem methods:  initOwner, initGroup, and initPermissions will not be invoked unless enablePosixFileAttributes=true.  

Mach5 tiers1-3 are currently running and have not encountered any issues.

-------------

Commit messages:
 - Only invoke initOwner, initGroup, and initPermissions when supportsPosix is true

Changes: https://git.openjdk.java.net/jdk/pull/8854/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8854&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287162
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8854.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8854/head:pull/8854

PR: https://git.openjdk.java.net/jdk/pull/8854

From rriggs at openjdk.java.net  Mon May 23 20:00:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 23 May 2022 20:00:01 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults [v2]
In-Reply-To: <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>
Message-ID: <TqMVPufXkfsmPDZ7AkKu3XPWlayGrFqey8oUS82PBTI=.7c45b137-7ccd-4cb9-859e-f5ff37fcc1ff@github.com>

On Mon, 23 May 2022 18:58:34 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> JDK-6725221 Standardize obtaining boolean properties with defaults
>
> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Alan and Jamil comments
>  - Merge
>  - reverse true.equals and false.equals changes
>  - Merge
>  - Merge
>  - first iteration

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8559

From aivanov at openjdk.java.net  Mon May 23 20:06:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 May 2022 20:06:57 GMT
Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base
 [v3]
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <3E93xe0v68L9AHsT3c5D58_5OdaSDEGtdg5ih7TTkfk=.45bed80f-be56-49e8-9dfb-a7fa70b9ea23@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright to 2022

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01-02

  Stats: 102 lines in 102 files changed: 0 ins; 0 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From sviswanathan at openjdk.java.net  Mon May 23 20:11:49 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Mon, 23 May 2022 20:11:49 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v3]
In-Reply-To: <v6oWG6skDA-bprsjHiUj65tq2JDbme68QCVr_kdTBKk=.f6b4845f-d91a-4a57-a9f2-ab05cbaa7acc@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <v6oWG6skDA-bprsjHiUj65tq2JDbme68QCVr_kdTBKk=.f6b4845f-d91a-4a57-a9f2-ab05cbaa7acc@github.com>
Message-ID: <5iVxsWodIft_Qbj8ZKCGmz-M4JFQebYwApckPrr5C6o=.77ea11c8-345a-477b-83f0-b1e5da16b7db@github.com>

On Sat, 21 May 2022 10:31:25 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
>> 
>> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>>     jne     label
>> 
>> into
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>> 
>> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
>> 
>>         xorl    ecx, ecx
>>         ucomiss xmm0, xmm1
>>         jnp     done
>>         pushf
>>         andq    [rsp], 0xffffff2b
>>         popf
>>     done:
>>         movl    eax, 1
>>         cmovel  eax, ecx
>> 
>> The patch changes this sequence into
>> 
>>     xorl    ecx, ecx
>>     ucomiss xmm0, xmm1
>>     movl    eax, 1
>>     cmovpl  eax, ecx
>>     cmovnel eax, ecx
>> 
>> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
>> 
>> The benchmark results are as follow:
>> 
>>                                                      Before              After
>>     Benchmark                      Mode  Cnt     Score     Error    Score     Error   Unit   Ratio
>>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  594.636 ?   8.922  ns/op    4.84
>>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  663.849 ?   3.656  ns/op    4.61
>>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  518.309 ? 107.352  ns/op    0.92
>>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  515.576 ?  14.669  ns/op    0.98
>>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  621.185 ?  11.935  ns/op    1.98
>>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  623.566 ?  15.206  ns/op    1.98
>>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  400.124 ?   0.762  ns/op    5.64
>>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  546.486 ?   1.509  ns/op    4.70
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments

Marked as reviewed by sviswanathan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From aivanov at openjdk.java.net  Mon May 23 20:46:23 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 May 2022 20:46:23 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
 [v2]
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <6pmdug3Hpy1LPgcb-OIdMP6XuOWpWYngOju7mFPdDV4=.a68d1c15-58a3-4ffa-b94d-a1a14666f9eb@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge master
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'an? an?' in source code
 - 8284209: Replace remaining usages of 'a the' in source code
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/5b7d066c...fab0a4bb

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01
  Stats: 50 lines in 40 files changed: 0 ins; 2 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From aturbanov at openjdk.java.net  Mon May 23 20:51:16 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 23 May 2022 20:51:16 GMT
Subject: RFR: 8287181: Avoid redundant HashMap.containsKey calls in
 InternalLocaleBuilder.setExtension
Message-ID: <Xzpw4lqoOLnSpSrkfIeCbh-Gq9Ru2BQpiYLuA5Wkn1o=.1f208f43-fe60-4e6c-8dcf-a23a625be047@github.com>

No need to separately perform `HashMap.containsKey` before `HashMap.remove` call. If key is present - it will be removed anyway. If it's not present, nothing will be deleted.

-------------

Commit messages:
 - [PATCH] Avoid redundant HashMap.containsKey calls in InternalLocaleBuilder

Changes: https://git.openjdk.java.net/jdk/pull/8488/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8488&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287181
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8488.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8488/head:pull/8488

PR: https://git.openjdk.java.net/jdk/pull/8488

From mcimadamore at openjdk.java.net  Mon May 23 21:11:52 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 May 2022 21:11:52 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
In-Reply-To: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
Message-ID: <H0RDR2kX9-RkvRhXXS_c-uow7aezCJ9iH60whVXCeDM=.dfda5d67-fe95-4d65-9800-acdcd9112dbb@github.com>

On Thu, 19 May 2022 13:05:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 428: Structured Concurrency (Incubator).
> 
> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

Marked as reviewed by mcimadamore (Reviewer).

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 88:

> 86:  * {@code join} method after forking.
> 87:  *
> 88:  * <p> StructuredTaskScope defines the {@link #shutdown() shutdown} method to shut down a

This sentence, because of the place where it appears, is a bit confusing. So far we only know about the fact that a scope has an owner thread. So it seems odd that shutdown could be called _while_ the owner thread is waiting on a `join`. Of course, then you read what's next, and you discover that: (a) shutdown might be called by a custom scope subclass and that (b) shutdown is confined to the threads contained in this task scope - but this definition is only given much later.

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 353:

> 351:      *
> 352:      * <p> The {@code handleComplete} method should be thread safe. It may be
> 353:      * invoked by several threads at around the same.

Something is missing? E.g. "at around the same TIME" ? (I'd suggest just using "concurrently")

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 376:

> 374:      *
> 375:      * <p> If this task scope is {@linkplain #shutdown() shutdown} (or in the process
> 376:      * of shutting down) then {@code fork} returns a Future representing a {@link

Future in plaintext?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From brian.goetz at oracle.com  Mon May 23 22:08:59 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 23 May 2022 18:08:59 -0400
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
In-Reply-To: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
Message-ID: <381e0979-ae04-63e5-df58-3cdb96bb8797@oracle.com>

This work is quite timely as we are now paving the way for primitive 
type patterns over in Project Amber, and also has a nontrivial 
connection with Valhalla.? If you'll pardon a brief digression...

Instanceof and casting work together in a familiar way: before you cast, 
you first ask instanceof -- but this is restricted currently to 
reference types.? But the pattern is obvious: instanceof is the 
precondition check for casting, which asks: "If I made this cast, would 
I like the answer."? There are currently two reasons to not like the 
answer: a CCE, or the operand is null (because, even though the cast 
would succeed, if you tried to use it as a member of that type, you 
wouldn't like the answer then.)

If we wanted to extend `instanceof` to primitive types, we are asking 
the same question: if I were to cast to this type, would I like the 
answer.? And casts involving primitives give us two more reasons to not 
like the answer: an NPE (due to unboxing), or loss of precision.? Which 
means that we have to specify in JLS 5.1 what cast with loss of 
precision means.? At the very least, we will want to align this work 
with that; the asXExact should be able to say "throws if the cast would 
lose precision", where "lose precision" is precisely defined by the JLS.

Separately, Project Valhalla will let us define new primitive-like 
types, such as HalfFloat and SuperLong. Conversions between primitives 
are currently specified in a complex table in JLS 5.1.? But surely we 
will want to support primitive widening conversions between HalfFloat 
and float (somehow; how we do this is a separate discussion.)? Which 
brings us back to pattern matching; narrowing casts are inherently 
partial, and declared patterns bring partiality into the "return type", 
and are the natural way (when we have it) to express things like "cast, 
but fail if you can't do so safely". This is preferable to throwing 
(which currently is the our choice.)? So it might be a little 
unfortunate to introduce throwing toXExactly now and then have to 
introduce separate patterns which signal precision loss by match 
failure.? (Though that's not the end of the world if there is some 
duplication.)

What this says is that the current proposal of toXExact is not the 
primitive, because we probably wouldn't want to implement a pattern in 
terms of the throwing version.

Converting from float/double to integral types is particularly tricky 
with -0.0.? Both answers kind of suck.? (This is a familiar situation, 
and these can be very difficult to resolve, as for each position, 
*someone* has decided the other position is untenable.)? I understand 
the rationale behind Michael H's "but its not exact", but let's not 
pretend one answer is good and the other sucks -- they both suck, and 
therefore the decision can be made on other factors.

So I have a few new wrinkles to add to the story:

 ?- We should wait until we have candidate JLS text for "cast conversion 
without loss of precision", and ensure the two are consistent, before 
pushing;
 ?- I not quite comfortable with settling the -0.0 issue just yet, there 
are some other explorations to complete first;
 ?- We should be prepared for the fact that we will, sometime soon, have 
to implement this whole set again as patterns that do not throw.








On 5/5/2022 6:18 AM, Raffaello Giulietti wrote:
> Add a family of "safe" cast methods.
>
> -------------
>
> Commit messages:
>   - 8279986: methods Math::asXExact for safely checked primitive casts
>   - 8279986: methods Math::asXExact for safely checked primitive casts
>   - 8279986: methods Math::asXExact for safely checked primitive casts
>
> Changes:https://git.openjdk.java.net/jdk/pull/8548/files
>   Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=8548&range=00
>    Issue:https://bugs.openjdk.java.net/browse/JDK-8279986
>    Stats: 615 lines in 2 files changed: 609 ins; 0 del; 6 mod
>    Patch:https://git.openjdk.java.net/jdk/pull/8548.diff
>    Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/8548/head:pull/8548
>
> PR:https://git.openjdk.java.net/jdk/pull/8548

From vlivanov at openjdk.java.net  Mon May 23 22:09:27 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 23 May 2022 22:09:27 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v8]
In-Reply-To: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
Message-ID: <cVl6j-1SCrE6OoO-A2-cUJKJE572Olmq4ZLxtcmX6uE=.e1fb169e-e792-4c86-aa73-0b6c96ff54ec@github.com>

On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284960: Integrating incremental patches.

Looks good!

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8425

From iklam at openjdk.java.net  Mon May 23 22:24:24 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 23 May 2022 22:24:24 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller
Message-ID: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>

This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode.

The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1).

However, the "hybrid checks" only considers the following controllers that Java cares about:

- cpu
- cpuacct
- cpuset
- blkio
- memory
- pids

If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert.


$ cat /proc/self/cgroup
1:freezer:/
0::/user.slice/user-1001.slice/session-85.scope


The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name).

-------------

Commit messages:
 - 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller

Changes: https://git.openjdk.java.net/jdk/pull/8858/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287107
  Stats: 116 lines in 3 files changed: 113 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8858.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8858/head:pull/8858

PR: https://git.openjdk.java.net/jdk/pull/8858

From kvn at openjdk.java.net  Mon May 23 23:11:36 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 23 May 2022 23:11:36 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v8]
In-Reply-To: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
Message-ID: <MIC5Sq_7Vvy7XAkLQ-HFQ0ydRv8XPHuBQhR53eSLQN0=.3b396db1-43fd-4348-b89c-ff8377281c91@github.com>

On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284960: Integrating incremental patches.

src/hotspot/cpu/x86/assembler_x86.cpp line 7934:

> 7932: 
> 7933: void Assembler::evplzcntd(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) {
> 7934:   assert(VM_Version::supports_avx512cd() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");

Please, split assert as in other instructions - it will help to understand failure better.

src/hotspot/cpu/x86/assembler_x86.cpp line 7946:

> 7944: 
> 7945: void Assembler::evplzcntq(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) {
> 7946:   assert(VM_Version::supports_avx512cd() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");

Split assert.

src/hotspot/cpu/x86/assembler_x86.cpp line 8173:

> 8171: 
> 8172: void Assembler::vinsertf32x4(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
> 8173:   assert(VM_Version::supports_evex(), "");

Hmm, did we never trigger this wrong assert because the use was guarded by correct check?

src/hotspot/cpu/x86/assembler_x86.cpp line 11720:

> 11718: 
> 11719: void Assembler::evpcompressb(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) {
> 11720:   assert(VM_Version::supports_avx512_vbmi2() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), "");

Split assert in this and following new instructions.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4455:

> 4453:       break;
> 4454:     default:
> 4455:       fatal("Unsupported type");

Print wrong type: `fatal("Unsupported type : %s", type2name(type));`
Below too.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4561:

> 4559:       case 4 : evpbroadcastd(dst, rtmp, vec_enc); break;
> 4560:       case 8 : evpbroadcastq(dst, rtmp, vec_enc); break;
> 4561:       default : ShouldNotReachHere(); break;

`ShouldNotReachHere` does not give any information in case of failure. Use `fatal()` which prints wrong `lane_size`.
Same below.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4666:

> 4664:       break;
> 4665:     default:
> 4666:       ShouldNotReachHere();

Use `fatal()`.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4693:

> 4691:       break;
> 4692:     default:
> 4693:       ShouldNotReachHere();

Use `fatal()`.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4732:

> 4730:     vector_reverse_byte(bt, dst, xtmp2, rtmp, vec_enc);
> 4731: 
> 4732:   } else if(!VM_Version::supports_avx512vlbw() && vec_enc == Assembler::AVX_512bit) {

No need to check `!VM_Version::supports_avx512vlbw()`.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4759:

> 4757:     vpandn(xtmp2, xtmp2, xtmp1, vec_enc);
> 4758:     vpsrlq(xtmp2, xtmp2, 1, vec_enc);
> 4759:     vporq(xtmp1, dst, xtmp2, vec_enc);

All 3 code snippets are the same except constants. Also similar code in `vector_reverse_byte64` for `short` type.
Consider factoring out it into separate method.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4819:

> 4817:       break;
> 4818:     default:
> 4819:       fatal("Unsupported type");

Print wring type.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4846:

> 4844:       break;
> 4845:     default:
> 4846:       fatal("Unsupported type");

Print wring type.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4892:

> 4890:       break;
> 4891:     default:
> 4892:       ShouldNotReachHere();

Use `fatal` and print type.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5018:

> 5016:       break;
> 5017:     default:
> 5018:       ShouldNotReachHere();

Use fatal and print type.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5037:

> 5035:       break;
> 5036:     default:
> 5037:       ShouldNotReachHere();

Use fatal and print type.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5056:

> 5054:       break;
> 5055:     default:
> 5056:       ShouldNotReachHere();

Use fatal and print type.

src/hotspot/cpu/x86/x86.ad line 8879:

> 8877:     // special handling should be removed.
> 8878:     if (bt == T_LONG && rbt == T_INT) {
> 8879:       if (VM_Version::supports_avx512vl()) {

Predicate say `!VM_Version::supports_avx512vl()`

src/hotspot/share/opto/node.hpp line 1006:

> 1004: 
> 1005:   // The node is a CountedLoopEnd with a mask annotation so as to emit a restore context
> 1006:   bool has_vector_mask_set() const { return (_flags & Flag_has_vector_mask_set) != 0; }

I don't see use of this flag.

src/hotspot/share/opto/vectorIntrinsics.cpp line 86:

> 84:     if ((mask_use_type & VecMaskUseLoad) != 0) {
> 85:       if (!Matcher::match_rule_supported_vector(Op_VectorLoadMask, num_elem, elem_bt) ||
> 86:           !Matcher::match_rule_supported_vector(Op_LoadVector, num_elem, T_BOOLEAN)) {

Add comment explaining new check. In follow ing places too.

src/hotspot/share/runtime/vmStructs.cpp line 1779:

> 1777:   declare_c2_type(CMoveVDNode, VectorNode)                                \
> 1778:   declare_c2_type(CompressVNode, VectorNode)                              \
> 1779:   declare_c2_type(ExpandVNode, VectorNode)                                \

Not all new nodes listed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From mseledtsov at openjdk.java.net  Mon May 23 23:18:36 2022
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 23 May 2022 23:18:36 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller
In-Reply-To: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
Message-ID: <zm8-THmQbLHof-VQbvZXRryDOJXRDsZVeEretxc_C1s=.6dfc5b47-c085-48f0-a374-e7c6e155f4e7@github.com>

On Mon, 23 May 2022 22:11:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode.
> 
> The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1).
> 
> However, the "hybrid checks" only considers the following controllers that Java cares about:
> 
> - cpu
> - cpuacct
> - cpuset
> - blkio
> - memory
> - pids
> 
> If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert.
> 
> 
> $ cat /proc/self/cgroup
> 1:freezer:/
> 0::/user.slice/user-1001.slice/session-85.scope
> 
> 
> The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name).

Marked as reviewed by mseledtsov (Committer).

Change looks good to me. Thanks for the fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From duke at openjdk.java.net  Mon May 23 23:49:41 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 23 May 2022 23:49:41 GMT
Subject: RFR: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
 [v3]
In-Reply-To: <v6oWG6skDA-bprsjHiUj65tq2JDbme68QCVr_kdTBKk=.f6b4845f-d91a-4a57-a9f2-ab05cbaa7acc@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
 <v6oWG6skDA-bprsjHiUj65tq2JDbme68QCVr_kdTBKk=.f6b4845f-d91a-4a57-a9f2-ab05cbaa7acc@github.com>
Message-ID: <ZmA_OX0JYX8vNUADuljNsH3ldcMEzuNVL3QojIZGq6M=.2a68db4f-e9b4-4eb9-a8fd-03d42b720c69@github.com>

On Sat, 21 May 2022 10:31:25 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
>> 
>> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>>     jne     label
>> 
>> into
>> 
>>     ucomiss xmm0, xmm0
>>     jp      label
>> 
>> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
>> 
>>         xorl    ecx, ecx
>>         ucomiss xmm0, xmm1
>>         jnp     done
>>         pushf
>>         andq    [rsp], 0xffffff2b
>>         popf
>>     done:
>>         movl    eax, 1
>>         cmovel  eax, ecx
>> 
>> The patch changes this sequence into
>> 
>>     xorl    ecx, ecx
>>     ucomiss xmm0, xmm1
>>     movl    eax, 1
>>     cmovpl  eax, ecx
>>     cmovnel eax, ecx
>> 
>> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
>> 
>> The benchmark results are as follow:
>> 
>>                                                      Before              After
>>     Benchmark                      Mode  Cnt     Score     Error    Score     Error   Unit   Ratio
>>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  594.636 ?   8.922  ns/op    4.84
>>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  663.849 ?   3.656  ns/op    4.61
>>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  518.309 ? 107.352  ns/op    0.92
>>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  515.576 ?  14.669  ns/op    0.98
>>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  621.185 ?  11.935  ns/op    1.98
>>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  623.566 ?  15.206  ns/op    1.98
>>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  400.124 ?   0.762  ns/op    5.64
>>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  546.486 ?   1.509  ns/op    4.70
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments

Thank you very much for your reviews and testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From duke at openjdk.java.net  Tue May 24 00:18:42 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 24 May 2022 00:18:42 GMT
Subject: Integrated: 8285973: x86_64: Improve fp comparison and cmove for eq/ne
In-Reply-To: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
References: <kLqU4Tk3y1YRgH87zHRkuc6TSTE0RmsIMf0WaSudOqs=.09939319-41c2-44e2-8ab8-b1ce4c8a8d9f@github.com>
Message-ID: <Nj_w7kzQqcpEx543NxNzsLmXbALxKiJMb3QX2r3suQQ=.908a2d16-acd1-48ba-a931-2b1a883f8f9e@github.com>

On Wed, 4 May 2022 01:59:17 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch optimises the matching rules for floating-point comparison with respects to eq/ne on x86-64
> 
> 1, When the inputs of a comparison is the same (i.e `isNaN` patterns), `ZF` is always set, so we don't need `cmpOpUCF2` for the eq/ne cases, which improves the sequence of `If (CmpF x x) (Bool ne)` from
> 
>     ucomiss xmm0, xmm0
>     jp      label
>     jne     label
> 
> into
> 
>     ucomiss xmm0, xmm0
>     jp      label
> 
> 2, The move rules for `cmpOpUCF2` is missing, which makes patterns such as `x == y ? 1 : 0` to fall back to `cmpOpU`, which have a really high cost of fixing the flags, such as
> 
>         xorl    ecx, ecx
>         ucomiss xmm0, xmm1
>         jnp     done
>         pushf
>         andq    [rsp], 0xffffff2b
>         popf
>     done:
>         movl    eax, 1
>         cmovel  eax, ecx
> 
> The patch changes this sequence into
> 
>     xorl    ecx, ecx
>     ucomiss xmm0, xmm1
>     movl    eax, 1
>     cmovpl  eax, ecx
>     cmovnel eax, ecx
> 
> 3, The patch also changes the pattern of `isInfinite` to be more optimised by using `Math.abs` to reduce 1 comparison and compares the result with `MAX_VALUE` since `>` is more optimised than `==` for floating-point types.
> 
> The benchmark results are as follow:
> 
>                                                      Before              After
>     Benchmark                      Mode  Cnt     Score     Error    Score     Error   Unit   Ratio
>     FPComparison.equalDouble       avgt    5  2876.242 ?  58.875  594.636 ?   8.922  ns/op    4.84
>     FPComparison.equalFloat        avgt    5  3062.430 ?  31.371  663.849 ?   3.656  ns/op    4.61
>     FPComparison.isFiniteDouble    avgt    5   475.749 ?  19.027  518.309 ? 107.352  ns/op    0.92
>     FPComparison.isFiniteFloat     avgt    5   506.525 ?  14.417  515.576 ?  14.669  ns/op    0.98
>     FPComparison.isInfiniteDouble  avgt    5  1232.800 ?  31.677  621.185 ?  11.935  ns/op    1.98
>     FPComparison.isInfiniteFloat   avgt    5  1234.708 ?  70.239  623.566 ?  15.206  ns/op    1.98
>     FPComparison.isNanDouble       avgt    5  2255.847 ?   7.238  400.124 ?   0.762  ns/op    5.64
>     FPComparison.isNanFloat        avgt    5  2567.044 ?  36.078  546.486 ?   1.509  ns/op    4.70
> 
> Thank you very much.

This pull request has now been integrated.

Changeset: c1db70d8
Author:    Quan Anh Mai <anhmdq99 at gmail.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c1db70d827f7ac81aa6c6646e2431f672c71c8dc
Stats:     704 lines in 4 files changed: 620 ins; 70 del; 14 mod

8285973: x86_64: Improve fp comparison and cmove for eq/ne

Reviewed-by: kvn, sviswanathan

-------------

PR: https://git.openjdk.java.net/jdk/pull/8525

From serb at openjdk.java.net  Tue May 24 00:43:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 24 May 2022 00:43:41 GMT
Subject: RFR: 8286849: Use @Stable for generic repositories
In-Reply-To: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>
References: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>
Message-ID: <uiYI_V2t-itzEnesSUVogXAuGRr2s2D8mYFkHWTXrcE=.0cb38e14-302b-4056-b95b-2297e8101c17@github.com>

On Tue, 17 May 2022 04:40:50 GMT, liach <duke at openjdk.java.net> wrote:

> Generic repositories, the implementation detail for generic information in core reflection, can be updated to use the `@Stable` annotation to replace their `volatile` access. Their existing accessor code is already safe, reading the cache fields only once.
> 
> In addition, fixed potentially non-thread-safe `genericInfo` access in `Method`, `Field`, and `RecordComponent`.

Just curious about any performance benefits of this patch?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8742

From duke at openjdk.java.net  Tue May 24 01:20:53 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 24 May 2022 01:20:53 GMT
Subject: RFR: 8286849: Use @Stable for generic repositories
In-Reply-To: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>
References: <3-iOiv3PbymtBaPWZyXn8J9zCQxrJRvfsNlQLCWea6Y=.1259786c-f2b3-4b99-8fd5-861cc7e2325a@github.com>
Message-ID: <ukSm8d9xn_Z--lUjIHDRWR6bAp0CkRRd8Z_DdsQn3hg=.3c8de70c-076a-432d-9c88-05e863a1bfbc@github.com>

On Tue, 17 May 2022 04:40:50 GMT, liach <duke at openjdk.java.net> wrote:

> Generic repositories, the implementation detail for generic information in core reflection, can be updated to use the `@Stable` annotation to replace their `volatile` access. Their existing accessor code is already safe, reading the cache fields only once.
> 
> In addition, fixed potentially non-thread-safe `genericInfo` access in `Method`, `Field`, and `RecordComponent`.

This should offer slight performance benefit if a reflection object has its generic information accessed frequently, as reading a stable field is faster than reading a volatile field for cached objects. If the `genericInfo` fields are updated by JVMTI then they need to be declared `volatile` instead. In addition, some of the `genericInfo` fields may have been not thread-safe for their multiple field reads.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8742

From jpai at openjdk.java.net  Tue May 24 01:33:02 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 24 May 2022 01:33:02 GMT
Subject: RFR: 8287162: (zipfs) Performance regression related to support
 for POSIX file permissions
In-Reply-To: <znseZkEwQfyr0ih8UtE3cxNsXelAnN2pULr5Tj-oq6o=.35ca3a29-097b-4d1a-a3ff-52a5ca83c2c1@github.com>
References: <znseZkEwQfyr0ih8UtE3cxNsXelAnN2pULr5Tj-oq6o=.35ca3a29-097b-4d1a-a3ff-52a5ca83c2c1@github.com>
Message-ID: <j26wkhPzjYiZr6azGrMmfElp1DyjlfAAwh51_7u248s=.bcd62a55-6f12-4c0d-9611-5f083570fd5a@github.com>

On Mon, 23 May 2022 19:47:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> This PR addresses the performance issue that is described in JDK-8287162.
> 
> With this fix,  the ZipFileSystem methods:  initOwner, initGroup, and initPermissions will not be invoked unless enablePosixFileAttributes=true.  
> 
> Mach5 tiers1-3 are currently running and have not encountered any issues.

Marked as reviewed by jpai (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8854

From darcy at openjdk.java.net  Tue May 24 04:22:02 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 24 May 2022 04:22:02 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
In-Reply-To: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
Message-ID: <65J16PuQZlKJZWmgGFK1He6GFCbRfEfqdEE-7ikNIac=.c0d67b30-b640-4781-b08f-682506487eaa@github.com>

On Thu, 19 May 2022 13:05:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of JEP 428: Structured Concurrency (Incubator).
> 
> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 237:

> 235:  * the task result is retrieved via its {@code Future}, or <i>happen-before</i> any actions
> 236:  * taken in a thread after {@linkplain #join() joining} of the task scope.
> 237:  *

Would a @-jls reference to the appropriate section of the memory model chapter help here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From jpai at openjdk.java.net  Tue May 24 04:54:52 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 24 May 2022 04:54:52 GMT
Subject: RFR: 8279031: Add API note to ToolProvider about being
 reusable/reentrant [v2]
In-Reply-To: <214conRfJyAdFNoHUsm_E8J_59VqLFYXvm6Z4PuYDrM=.67516d8e-5a7f-4871-97e9-4844374405a4@github.com>
References: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
 <214conRfJyAdFNoHUsm_E8J_59VqLFYXvm6Z4PuYDrM=.67516d8e-5a7f-4871-97e9-4844374405a4@github.com>
Message-ID: <foT0oTvXLDdvRGtrR9lXHm5Lt-_RPKZDuDpeAyQiJ_o=.423f0e65-6e15-48d0-92d9-e2530d7e9181@github.com>

On Mon, 23 May 2022 10:38:43 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This commit adds an  API note to ToolProvider about being reusable/reentrant.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/spi/ToolProvider.java
>   
>   Co-authored-by: Anthony Vanelverdinghe <dev at anthonyv.be>

src/java.base/share/classes/java/util/spi/ToolProvider.java line 59:

> 57:  * a tool may be the target of multiple {@code run} method invocations,
> 58:  * and reentrant means that multiple invocations of {@code run} may occur
> 59:  * concurrently.

Hello @sormuras,

> reentrant means that multiple invocations of {@code run} may occur
> concurrently.

My understanding of re-entrant was that the same method could be re-invoked on the same thread while the current method execution is in progress (a recursion). Whereas "multiple invocations may occur concurrently" sounds more like multiple threads invoking this concurrently (i.e. thread-safety). Which of these 2 characteristics are we recommending here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8833

From jpai at openjdk.java.net  Tue May 24 05:01:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 24 May 2022 05:01:46 GMT
Subject: RFR: 8287121: Fix typo in jlink's description resource key lookup
In-Reply-To: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
References: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
Message-ID: <_OCkHftNpxNB7-sLQhu7M7fos_zUGe304YSbeIdRQ8g=.afcba6cc-a5b7-49ca-91b2-ff1231491680@github.com>

On Sun, 22 May 2022 05:58:25 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Commit https://github.com/openjdk/jdk/commit/655500a4f5e3abcff176599604deceefb6ca6640 for issue [JDK-8286654](https://bugs.openjdk.java.net/browse/JDK-8286654) added an optional description accessor on the `ToolProvider` interface. It included a typo in` jlink`'s description resource key lookup: `"jlink.desciption"`
> 
> This follow-up commit fixes the typo by adding the missing `r` character: `"jlink.description"`.
> 
> This commit also also adds an automated check that ensures all current and future tool provider implementations within the JDK don't throw an exception when invoking their name and description accessor methods. Specific tool names and descriptions are not expected by this general test.

test/jdk/java/util/spi/ToolProviderDescriptionTest.java line 40:

> 38:     public static void main(String... args) throws Exception {
> 39:         List<String> descriptions = listToolDescriptions();
> 40:         if (descriptions.isEmpty()) {

Hello @sormuras,
Won't this condition always be "false", because from what I see in this test code, the `descriptions` list will never be empty since in the `describeTool` method of this test we always return a `String` instance to be added to the `List`, even if there's no `description` for the `ToolProvider` instance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8825

From alanb at openjdk.java.net  Tue May 24 05:19:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 05:19:42 GMT
Subject: RFR: 8287162: (zipfs) Performance regression related to support
 for POSIX file permissions
In-Reply-To: <znseZkEwQfyr0ih8UtE3cxNsXelAnN2pULr5Tj-oq6o=.35ca3a29-097b-4d1a-a3ff-52a5ca83c2c1@github.com>
References: <znseZkEwQfyr0ih8UtE3cxNsXelAnN2pULr5Tj-oq6o=.35ca3a29-097b-4d1a-a3ff-52a5ca83c2c1@github.com>
Message-ID: <Jfv-_KTkKGsokRwOczAomKSD0-2VU73F3LFhoL6768Y=.d6098bf9-ec24-4e13-9c74-fb2357657d83@github.com>

On Mon, 23 May 2022 19:47:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> This PR addresses the performance issue that is described in JDK-8287162.
> 
> With this fix,  the ZipFileSystem methods:  initOwner, initGroup, and initPermissions will not be invoked unless enablePosixFileAttributes=true.  
> 
> Mach5 tiers1-3 are currently running and have not encountered any issues.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8854

From jpai at openjdk.java.net  Tue May 24 05:41:49 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 24 May 2022 05:41:49 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v3]
In-Reply-To: <Uh30nZyDeqt2ARI5Y-FXoBKabCJxYebhgaimCdixxOo=.87c7c3c5-6310-45f2-b9b8-b390052c1f9e@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
 <Uh30nZyDeqt2ARI5Y-FXoBKabCJxYebhgaimCdixxOo=.87c7c3c5-6310-45f2-b9b8-b390052c1f9e@github.com>
Message-ID: <1XOcr-j-27aYsiJnYQ5UYUaBTO_stl-hZlnsKulgW3c=.1d384bf9-e88b-407d-9423-6dc6234025cd@github.com>

On Fri, 20 May 2022 18:22:47 GMT, liach <duke at openjdk.java.net> wrote:

>> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of `Class.forName(String)`. `make test TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new `LazyInitializationTest` failing the eager initialization check on the baseline and passing with this patch.
>> 
>> On a side note, this might reduce the number of methods that can be encoded in a proxy due to code attribute size restrictions; we probably would address that in another issue, as we never mandated a count of methods that the proxy must be able to implement.
>> 
>> Mandy, would you mind review this?
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the try catch block as it doesn't throw checked exceptions

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 605:

> 603:         mv.visitLdcInsn(Type.getObjectType(dotToSlash(className)));
> 604:         mv.visitMethodInsn(INVOKEVIRTUAL, JL_CLASS,
> 605:                 "getClassLoader", "()" + LJL_CLASSLOADER, false);

Hello @liach, should this instead be using the (application supplied) `loader` returned by the call to `ProxyGenerator.getClassLoader()` or maybe the `loader` member in the `ProxyGenerator` itself?

test/jdk/java/lang/reflect/Proxy/LazyInitializationTest.java line 56:

> 54: 
> 55:         value.m(new Parameter());
> 56:         Assert.assertTrue(initialized, "parameter type initialized after instantiation");

> "parameter type initialized after instantiation"

Since this is the text that gets displayed/reported when the assertion fails, should this instead be "parameter type not initialized"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8800

From cstein at openjdk.java.net  Tue May 24 05:51:01 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Tue, 24 May 2022 05:51:01 GMT
Subject: RFR: 8279031: Add API note to ToolProvider about being
 reusable/reentrant [v2]
In-Reply-To: <foT0oTvXLDdvRGtrR9lXHm5Lt-_RPKZDuDpeAyQiJ_o=.423f0e65-6e15-48d0-92d9-e2530d7e9181@github.com>
References: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
 <214conRfJyAdFNoHUsm_E8J_59VqLFYXvm6Z4PuYDrM=.67516d8e-5a7f-4871-97e9-4844374405a4@github.com>
 <foT0oTvXLDdvRGtrR9lXHm5Lt-_RPKZDuDpeAyQiJ_o=.423f0e65-6e15-48d0-92d9-e2530d7e9181@github.com>
Message-ID: <Yju6iNKVfrxoI3lUhmYPgSjJuvUL2-Gsl6CsqrMQjns=.ed606f94-3b34-4d6c-a539-92bdcb250af6@github.com>

On Tue, 24 May 2022 04:50:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/util/spi/ToolProvider.java
>>   
>>   Co-authored-by: Anthony Vanelverdinghe <dev at anthonyv.be>
>
> src/java.base/share/classes/java/util/spi/ToolProvider.java line 59:
> 
>> 57:  * a tool may be the target of multiple {@code run} method invocations,
>> 58:  * and reentrant means that multiple invocations of {@code run} may occur
>> 59:  * concurrently.
> 
> Hello @sormuras,
> 
>> reentrant means that multiple invocations of {@code run} may occur
>> concurrently.
> 
> My understanding of re-entrant was that the same method could be re-invoked on the same thread while the current method execution is in progress (a recursion). Whereas "multiple invocations may occur concurrently" sounds more like multiple threads invoking this concurrently (i.e. thread-safety). Which of these 2 characteristics are we recommending here?

According to https://wikidiff.com/reentrant/reusable "reentrant" includes/spans both characteristics:

> (programming) That may be executed more than once at a time either by different threads, or because of recursion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8833

From cstein at openjdk.java.net  Tue May 24 06:00:41 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Tue, 24 May 2022 06:00:41 GMT
Subject: RFR: 8287121: Fix typo in jlink's description resource key lookup
In-Reply-To: <_OCkHftNpxNB7-sLQhu7M7fos_zUGe304YSbeIdRQ8g=.afcba6cc-a5b7-49ca-91b2-ff1231491680@github.com>
References: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
 <_OCkHftNpxNB7-sLQhu7M7fos_zUGe304YSbeIdRQ8g=.afcba6cc-a5b7-49ca-91b2-ff1231491680@github.com>
Message-ID: <8KcmHuTEKxVrnVvw-gdzgNWVY7uSNZyGjCYSGH3FRx0=.b9ad71ea-6aec-46f6-af15-26454c86276f@github.com>

On Tue, 24 May 2022 04:58:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Commit https://github.com/openjdk/jdk/commit/655500a4f5e3abcff176599604deceefb6ca6640 for issue [JDK-8286654](https://bugs.openjdk.java.net/browse/JDK-8286654) added an optional description accessor on the `ToolProvider` interface. It included a typo in` jlink`'s description resource key lookup: `"jlink.desciption"`
>> 
>> This follow-up commit fixes the typo by adding the missing `r` character: `"jlink.description"`.
>> 
>> This commit also also adds an automated check that ensures all current and future tool provider implementations within the JDK don't throw an exception when invoking their name and description accessor methods. Specific tool names and descriptions are not expected by this general test.
>
> test/jdk/java/util/spi/ToolProviderDescriptionTest.java line 40:
> 
>> 38:     public static void main(String... args) throws Exception {
>> 39:         List<String> descriptions = listToolDescriptions();
>> 40:         if (descriptions.isEmpty()) {
> 
> Hello @sormuras,
> Won't this condition always be "false", because from what I see in this test code, the `descriptions` list will never be empty since in the `describeTool` method of this test we always return a `String` instance to be added to the `List`, even if there's no `description` for the `ToolProvider` instance.

The list will be empty, if no `ToolProvider` service is observable at all. For example, when running `java` with `--limit-module java.base` - which doesn't provide an implemention of `ToolProvider` as of today.

This test checks that all observable tools don't throw on calling their `name()` and `description()` accessors.

This test does not care for proper results being returned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8825

From duke at openjdk.java.net  Tue May 24 06:47:56 2022
From: duke at openjdk.java.net (Anthony Vanelverdinghe)
Date: Tue, 24 May 2022 06:47:56 GMT
Subject: RFR: 8279031: Add API note to ToolProvider about being
 reusable/reentrant [v2]
In-Reply-To: <foT0oTvXLDdvRGtrR9lXHm5Lt-_RPKZDuDpeAyQiJ_o=.423f0e65-6e15-48d0-92d9-e2530d7e9181@github.com>
References: <b1-ctSX66cllbIuVgp1Sgg6UjiLG4oat4bNNnPJTT1w=.cf49c148-f0ce-4cbd-919d-293f10fe9ad3@github.com>
 <214conRfJyAdFNoHUsm_E8J_59VqLFYXvm6Z4PuYDrM=.67516d8e-5a7f-4871-97e9-4844374405a4@github.com>
 <foT0oTvXLDdvRGtrR9lXHm5Lt-_RPKZDuDpeAyQiJ_o=.423f0e65-6e15-48d0-92d9-e2530d7e9181@github.com>
Message-ID: <QjJjyfHEXN6B2GBjPAR2RJimugkiFHF1DNeiaE8kIhQ=.168db6de-7b51-409f-a068-cc1e53de011d@github.com>

On Tue, 24 May 2022 04:50:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/util/spi/ToolProvider.java
>>   
>>   Co-authored-by: Anthony Vanelverdinghe <dev at anthonyv.be>
>
> src/java.base/share/classes/java/util/spi/ToolProvider.java line 59:
> 
>> 57:  * a tool may be the target of multiple {@code run} method invocations,
>> 58:  * and reentrant means that multiple invocations of {@code run} may occur
>> 59:  * concurrently.
> 
> Hello @sormuras,
> 
>> reentrant means that multiple invocations of {@code run} may occur
>> concurrently.
> 
> My understanding of re-entrant was that the same method could be re-invoked on the same thread while the current method execution is in progress (a recursion). Whereas "multiple invocations may occur concurrently" sounds more like multiple threads invoking this concurrently (i.e. thread-safety). Which of these 2 characteristics are we recommending here?

I agree with @jaikiran that reentrant is much more common in the sense of "on the same thread". Plus that the JDK itself uses "ReentrantLock" in this meaning. The JDK uses either "thread-safe" or "synchronized" for the "multiple threads" meaning.

Actually, being thread-safe implies being reusable, so I'd just phrase it as:

> It is recommended that tools implementing this interface are either
> thread-safe, or clearly document any limitations and restrictions.

Also: should this be an `@implNote`, rather than an `@apiNote`, since it's about "tools implementing this interface"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8833

From clanger at openjdk.java.net  Tue May 24 06:57:39 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 24 May 2022 06:57:39 GMT
Subject: RFR: 8287162: (zipfs) Performance regression related to support
 for POSIX file permissions
In-Reply-To: <znseZkEwQfyr0ih8UtE3cxNsXelAnN2pULr5Tj-oq6o=.35ca3a29-097b-4d1a-a3ff-52a5ca83c2c1@github.com>
References: <znseZkEwQfyr0ih8UtE3cxNsXelAnN2pULr5Tj-oq6o=.35ca3a29-097b-4d1a-a3ff-52a5ca83c2c1@github.com>
Message-ID: <bqOa1QkmcEfQff9Y89F4hRSXwumSO-37j0zcW7sPKUU=.39db9f7b-58ab-438d-b545-1603b536016f@github.com>

On Mon, 23 May 2022 19:47:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> This PR addresses the performance issue that is described in JDK-8287162.
> 
> With this fix,  the ZipFileSystem methods:  initOwner, initGroup, and initPermissions will not be invoked unless enablePosixFileAttributes=true.  
> 
> Mach5 tiers1-3 are currently running and have not encountered any issues.

Marked as reviewed by clanger (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8854

From shade at openjdk.java.net  Tue May 24 07:05:49 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 May 2022 07:05:49 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
Message-ID: <FesuBCg2Skfbo6BcpAiermc4X7t255Oa7gU3rYZS_ms=.a11a7113-1fa9-49d2-a566-44386018d104@github.com>

On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>>  - [x] GHA run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another release test

GHA run completes fine on x86_32. There are unrelated Windows x86_64 failures in javac land, to be handled separately. 

Please approve, @AlanBateman, @mcimadamore and others?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From ngasson at openjdk.java.net  Tue May 24 08:02:46 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 24 May 2022 08:02:46 GMT
Subject: RFR: 8287158: Explicitly reject unsupported call shapes on
 macos-aarch64 in mainline
In-Reply-To: <jzT8uoRxxN4ZEXD-3aFO2eLIJJYSVpw3R_gYQNls9GM=.95b5ec65-9aad-42f9-894f-598e70ad449f@github.com>
References: <jzT8uoRxxN4ZEXD-3aFO2eLIJJYSVpw3R_gYQNls9GM=.95b5ec65-9aad-42f9-894f-598e70ad449f@github.com>
Message-ID: <9pXkTrCEQi3HmQzsSrygPOD2j2G7FuTD1JFERMAlQ2A=.ed86ce36-857f-4d0b-9798-7dbde257ab9f@github.com>

On Mon, 23 May 2022 12:27:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Bring in changes from the panama-foreign repo
> 
> These changes pertain to explicitly rejecting unsupported call shapes on macos-aarch64.
> 
> Original PRs:
> 1. https://github.com/openjdk/panama-foreign/pull/676
> 2. https://github.com/openjdk/panama-foreign/pull/677
> 
> Testing: `jdk_foreign` on linux-aarch64-debug, macosx-aarch64-debug, linux-x64-debug, macosx-x64-debug, and windows-x64-debug

Marked as reviewed by ngasson (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8842

From mcimadamore at openjdk.java.net  Tue May 24 08:10:37 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 08:10:37 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
Message-ID: <bHiUdAZBz9ZlheIyGEwNibwc40zLEVeoC59cL5Ylaus=.7e77c753-a485-4482-a0c3-8e6a1612bfde@github.com>

On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>>  - [x] GHA run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another release test

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From mcimadamore at openjdk.java.net  Tue May 24 09:36:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 09:36:31 GMT
Subject: RFR: 8287206: Use WrongThreadException for confinement errors
Message-ID: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>

This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors.

-------------

Commit messages:
 - Merge branch 'master' into wrong_thread_ex
 - Initial push

Changes: https://git.openjdk.java.net/jdk/pull/8865/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8865&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287206
  Stats: 254 lines in 12 files changed: 150 ins; 1 del; 103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8865.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8865/head:pull/8865

PR: https://git.openjdk.java.net/jdk/pull/8865

From mcimadamore at openjdk.java.net  Tue May 24 09:36:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 09:36:31 GMT
Subject: RFR: 8287206: Use WrongThreadException for confinement errors
In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
Message-ID: <gMtsStHyxFAA67iIlqEgSDfyh9AaQ4NngyCMgaNtJ7g=.aaa7a49e-2a73-4253-8b9f-d1fee5fdfde5@github.com>

On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors.

javadoc:

http://cr.openjdk.java.net/~mcimadamore/8287206/v1/javadoc/java.base/module-summary.html

specdiff:

http://cr.openjdk.java.net/~mcimadamore/8287206/v1/specdiff_out/overview-summary.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/8865

From alanb at openjdk.java.net  Tue May 24 09:38:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 09:38:42 GMT
Subject: RFR: 8287206: Use WrongThreadException for confinement errors
In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
Message-ID: <nbzirOlRxSzBmr8cu0euP_ELJKXYOCdiR67Cflf3C7o=.4dce714a-5e18-419a-a883-b34c86163fe8@github.com>

On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8865

From alanb at openjdk.java.net  Tue May 24 09:46:34 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 09:46:34 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <FesuBCg2Skfbo6BcpAiermc4X7t255Oa7gU3rYZS_ms=.a11a7113-1fa9-49d2-a566-44386018d104@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
 <FesuBCg2Skfbo6BcpAiermc4X7t255Oa7gU3rYZS_ms=.a11a7113-1fa9-49d2-a566-44386018d104@github.com>
Message-ID: <dQ7MGIpcYunGjaTPzt_83AhLoAz9X-3y0BYxMIGDDeA=.0354b553-1f11-42fd-a28b-f9909ae57eca@github.com>

On Tue, 24 May 2022 07:01:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Please approve, @AlanBateman, @mcimadamore and others?

Okay with me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From aivanov at openjdk.java.net  Tue May 24 09:52:29 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 09:52:29 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
 [v3]
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <yDxT1sZCfM9b18MbUqSFDeyieqOfB5aBWMLKNxZEeYg=.8278ad27-ca58-4bf7-a236-d79604a6bff9@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright to 2022

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8771/files
  - new: https://git.openjdk.java.net/jdk/pull/8771/files/fab0a4bb..4d529f79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01-02

  Stats: 24 lines in 24 files changed: 0 ins; 0 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From lancea at openjdk.java.net  Tue May 24 09:58:42 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 24 May 2022 09:58:42 GMT
Subject: RFR: 8284209: Replace remaining usages of 'a the' in source code
 [v3]
In-Reply-To: <yDxT1sZCfM9b18MbUqSFDeyieqOfB5aBWMLKNxZEeYg=.8278ad27-ca58-4bf7-a236-d79604a6bff9@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
 <yDxT1sZCfM9b18MbUqSFDeyieqOfB5aBWMLKNxZEeYg=.8278ad27-ca58-4bf7-a236-d79604a6bff9@github.com>
Message-ID: <orVtBes_pss1zNktMdUeKjQeZmAHhREnRo2NXmb4Ip0=.deb262e2-aa59-4235-9308-4232698603d2@github.com>

On Tue, 24 May 2022 09:52:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> It's the last issue in the series, and it still touches different areas of the code.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright to 2022

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8771

From alanb at openjdk.java.net  Tue May 24 10:07:53 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 10:07:53 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
In-Reply-To: <nkRgejFGcz9Cx5U5dDTUjbaS24sVO6OUkafoJD9vzq4=.0600993b-e758-4064-8449-cabd0e6127ad@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <nkRgejFGcz9Cx5U5dDTUjbaS24sVO6OUkafoJD9vzq4=.0600993b-e758-4064-8449-cabd0e6127ad@github.com>
Message-ID: <37Y0qWfNAfS2_selvpRuM5as4A0lZmkGCIzDAN1jjdU=.b3f06a29-a14a-4e2a-a0b8-4c7c042cf68a@github.com>

On Mon, 23 May 2022 13:11:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>> 
>> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 54:
> 
>> 52: 
>> 53: /**
>> 54:  * A basic API for <em>structured concurrency</em>. StructuredTaskScope supports cases
> 
> Should StructuredTaskScope in this class-level API doc comment be surrounded by `{@code }` to appear in code font?

Okay, there are quite a few of these so I may have to adjust some of the lines to avoid too many inconsistent line lengths.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From alanb at openjdk.java.net  Tue May 24 10:07:57 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 10:07:57 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
In-Reply-To: <H0RDR2kX9-RkvRhXXS_c-uow7aezCJ9iH60whVXCeDM=.dfda5d67-fe95-4d65-9800-acdcd9112dbb@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <H0RDR2kX9-RkvRhXXS_c-uow7aezCJ9iH60whVXCeDM=.dfda5d67-fe95-4d65-9800-acdcd9112dbb@github.com>
Message-ID: <iHSuaWyZbaehqdW4MXcQwE0znNBA7a17-dA2hKvzvGA=.61dceb5c-5b9c-4263-9d6f-09c305636655@github.com>

On Mon, 23 May 2022 21:09:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>> 
>> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 88:
> 
>> 86:  * {@code join} method after forking.
>> 87:  *
>> 88:  * <p> StructuredTaskScope defines the {@link #shutdown() shutdown} method to shut down a
> 
> This sentence, because of the place where it appears, is a bit confusing. So far we only know about the fact that a scope has an owner thread. So it seems odd that shutdown could be called _while_ the owner thread is waiting on a `join`. Of course, then you read what's next, and you discover that: (a) shutdown might be called by a custom scope subclass and that (b) shutdown is confined to the threads contained in this task scope - but this definition is only given much later.

I see your point. The intention is to introduce all the public methods before introducing the subclasses or policies. I think I can adjust this sentence to make it clear that a subtask may call shutdown while the owner is waiting in join.

> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 353:
> 
>> 351:      *
>> 352:      * <p> The {@code handleComplete} method should be thread safe. It may be
>> 353:      * invoked by several threads at around the same.
> 
> Something is missing? E.g. "at around the same TIME" ? (I'd suggest just using "concurrently")

Thanks, it was supposed to say "around the same time" but saying "concurrently" would be better.

> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 376:
> 
>> 374:      *
>> 375:      * <p> If this task scope is {@linkplain #shutdown() shutdown} (or in the process
>> 376:      * of shutting down) then {@code fork} returns a Future representing a {@link
> 
> Future in plaintext?

Yes, Daniel also pointed this point that there are a few uses of "StructuredTaskScope" that should also use {@code ...}.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From alanb at openjdk.java.net  Tue May 24 10:08:00 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 10:08:00 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
In-Reply-To: <65J16PuQZlKJZWmgGFK1He6GFCbRfEfqdEE-7ikNIac=.c0d67b30-b640-4781-b08f-682506487eaa@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <65J16PuQZlKJZWmgGFK1He6GFCbRfEfqdEE-7ikNIac=.c0d67b30-b640-4781-b08f-682506487eaa@github.com>
Message-ID: <DulTwys2QXG2hFxmRediGAw1kY0OmCSnGZefz-Si2e0=.3f910309-25f6-4799-b24f-6348bf4a6103@github.com>

On Tue, 24 May 2022 04:18:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>> 
>> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 237:
> 
>> 235:  * the task result is retrieved via its {@code Future}, or <i>happen-before</i> any actions
>> 236:  * taken in a thread after {@linkplain #join() joining} of the task scope.
>> 237:  *
> 
> Would a @-jls reference to the appropriate section of the memory model chapter help here?

Yes, it can reference JLS 17.4.5.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From cstein at openjdk.java.net  Tue May 24 10:17:05 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Tue, 24 May 2022 10:17:05 GMT
Subject: Integrated: 8287121: Fix typo in jlink's description resource key
 lookup
In-Reply-To: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
References: <Z9T0T2oUjyfStg3kFBS6beWkiE38UxRzSWWxtmmTv4A=.359e5d07-ccb5-48d4-af16-f576d6ece273@github.com>
Message-ID: <eIeUsE-khxVIFOUo7slu1z40PB-g4Debqx_TuuZJads=.84011d47-123d-4ad5-aef9-19a515d9675e@github.com>

On Sun, 22 May 2022 05:58:25 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Commit https://github.com/openjdk/jdk/commit/655500a4f5e3abcff176599604deceefb6ca6640 for issue [JDK-8286654](https://bugs.openjdk.java.net/browse/JDK-8286654) added an optional description accessor on the `ToolProvider` interface. It included a typo in` jlink`'s description resource key lookup: `"jlink.desciption"`
> 
> This follow-up commit fixes the typo by adding the missing `r` character: `"jlink.description"`.
> 
> This commit also also adds an automated check that ensures all current and future tool provider implementations within the JDK don't throw an exception when invoking their name and description accessor methods. Specific tool names and descriptions are not expected by this general test.

This pull request has now been integrated.

Changeset: a0f6dd32
Author:    Christian Stein <cstein at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a0f6dd329139337a5f48557594fa67fa5b9af3eb
Stats:     58 lines in 2 files changed: 57 ins; 0 del; 1 mod

8287121: Fix typo in jlink's description resource key lookup

Reviewed-by: alanb, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/8825

From sgehwolf at openjdk.java.net  Tue May 24 10:26:01 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 10:26:01 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller
In-Reply-To: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
Message-ID: <EisSyVHbjSUIyBsszUjM97_OwD8Jt2cBIzSpXZpAEu8=.c62a5c40-e727-4f27-96d5-c7e5087725f0@github.com>

On Mon, 23 May 2022 22:11:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode.
> 
> The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1).
> 
> However, the "hybrid checks" only considers the following controllers that Java cares about:
> 
> - cpu
> - cpuacct
> - cpuset
> - blkio
> - memory
> - pids
> 
> If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert.
> 
> 
> $ cat /proc/self/cgroup
> 1:freezer:/
> 0::/user.slice/user-1001.slice/session-85.scope
> 
> 
> The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name).

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 155:

> 153:                 // There are some controllers (such as freezer) that Java doesn't
> 154:                 // care about. Just ignore them. These are not considered in the
> 155:                 // anyCgroupsV1Controller/anyCgroupsV1Controller checks.

It's not clear why this `default` is necessary. Could we just add the comment like so:


// Intentional fall-through. There are controllers (such as freezer) that
// Java doesn't care about. Just ignore them. Only listed controllers are
// considered in the anyCgroupsV1Controller/anyCgroupsV2Controller checks.

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 229:

> 227:         String name = tokens[1];
> 228:         if (!name.equals("")) {
> 229:             // This is probably a v1 controller that we have ignored (e.g., freezer)

Could we add an assertion that the controller isn't in the `infos` map?

           if (!name.equals("")) {
            // This must be a v1 controller that we have ignored (e.g., freezer)
            assert infos.get(name) == null;
            return;
         }

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From alanb at openjdk.java.net  Tue May 24 10:41:59 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 10:41:59 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v2]
In-Reply-To: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
Message-ID: <zaEKOTzWmnpRf1Llw19wRkRelLnpjKjzhcNX0TkqyPY=.3295e7d7-5bb6-4526-a1f9-ed6a6ffde5c4@github.com>

> This is the implementation of JEP 428: Structured Concurrency (Incubator).
> 
> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

Alan Bateman 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 six additional commits since the last revision:

 - Use {@code ...}, replace task->subtask, fix typos, add jls ref
 - Merge
 - @ignore StructuredThreadDumpTest until test infra in place
 - Refresh
 - Merge
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8787/files
  - new: https://git.openjdk.java.net/jdk/pull/8787/files/6a9553b9..c72f0330

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8787&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8787&range=00-01

  Stats: 6142 lines in 192 files changed: 3679 ins; 1909 del; 554 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8787/head:pull/8787

PR: https://git.openjdk.java.net/jdk/pull/8787

From mcimadamore at openjdk.java.net  Tue May 24 10:57:07 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 10:57:07 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v2]
In-Reply-To: <zaEKOTzWmnpRf1Llw19wRkRelLnpjKjzhcNX0TkqyPY=.3295e7d7-5bb6-4526-a1f9-ed6a6ffde5c4@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <zaEKOTzWmnpRf1Llw19wRkRelLnpjKjzhcNX0TkqyPY=.3295e7d7-5bb6-4526-a1f9-ed6a6ffde5c4@github.com>
Message-ID: <0ImeO1neNjHytwzg3TcoZZKP_bwbK0WhxBhB6pJ9zto=.d04425d4-89d4-4c22-8747-73e00b2dc5ab@github.com>

On Tue, 24 May 2022 10:41:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>> 
>> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.
>
> Alan Bateman 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 six additional commits since the last revision:
> 
>  - Use {@code ...}, replace task->subtask, fix typos, add jls ref
>  - Merge
>  - @ignore StructuredThreadDumpTest until test infra in place
>  - Refresh
>  - Merge
>  - Initial commit

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 214:

> 212:  * <h2><a id="TreeStructure">Tree structure</a></h2>
> 213:  *
> 214:  * StructuredTaskScopes form a tree where parent-child relations are established

Should we mention what happens in the owner thread completes its execution and the scope's `close` method has not been called? I think that, as discussed offline, the fact that the thread will attempt to close any nested scopes when terminating is an important aspect of this API.

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 1110:

> 1108:          * invoked {@link #join() join} (or {@link #joinUntil(Instant) joinUntil}).
> 1109:          * The behavior of this method is unspecified when invoking this method before
> 1110:          * the {@code join} is invoked.

Suggestion:

         * {@link #join} is invoked.

test/jdk/jdk/incubator/concurrent/StructuredTaskScope/StructuredThreadDumpTest.java line 200:

> 198:     }
> 199: 
> 200: }

Watch out for the newline here

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From mcimadamore at openjdk.java.net  Tue May 24 10:57:09 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 10:57:09 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v2]
In-Reply-To: <0ImeO1neNjHytwzg3TcoZZKP_bwbK0WhxBhB6pJ9zto=.d04425d4-89d4-4c22-8747-73e00b2dc5ab@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <zaEKOTzWmnpRf1Llw19wRkRelLnpjKjzhcNX0TkqyPY=.3295e7d7-5bb6-4526-a1f9-ed6a6ffde5c4@github.com>
 <0ImeO1neNjHytwzg3TcoZZKP_bwbK0WhxBhB6pJ9zto=.d04425d4-89d4-4c22-8747-73e00b2dc5ab@github.com>
Message-ID: <RyZy9UiX0NHTLIxGhDWVJJsc1IyCITdOF6TPbW13qB0=.27661012-247b-4e4b-bf39-b203a21dced0@github.com>

On Tue, 24 May 2022 10:44:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Alan Bateman 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 six additional commits since the last revision:
>> 
>>  - Use {@code ...}, replace task->subtask, fix typos, add jls ref
>>  - Merge
>>  - @ignore StructuredThreadDumpTest until test infra in place
>>  - Refresh
>>  - Merge
>>  - Initial commit
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 1110:
> 
>> 1108:          * invoked {@link #join() join} (or {@link #joinUntil(Instant) joinUntil}).
>> 1109:          * The behavior of this method is unspecified when invoking this method before
>> 1110:          * the {@code join} is invoked.
> 
> Suggestion:
> 
>          * {@link #join} is invoked.

More generally, I see that you used `{@code ... }` in a lot of places where `{@link ... }` could also be used. In some of those places (like this one) where there is a clear cross-reference, I think `@link` could be preferrable. The only case where `@code` is fine is when referring to the name of the class itself (e.g. `{@code StructuredTaskScope}`). But of course this is subjective.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From mcimadamore at openjdk.java.net  Tue May 24 10:57:09 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 10:57:09 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v2]
In-Reply-To: <RyZy9UiX0NHTLIxGhDWVJJsc1IyCITdOF6TPbW13qB0=.27661012-247b-4e4b-bf39-b203a21dced0@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <zaEKOTzWmnpRf1Llw19wRkRelLnpjKjzhcNX0TkqyPY=.3295e7d7-5bb6-4526-a1f9-ed6a6ffde5c4@github.com>
 <0ImeO1neNjHytwzg3TcoZZKP_bwbK0WhxBhB6pJ9zto=.d04425d4-89d4-4c22-8747-73e00b2dc5ab@github.com>
 <RyZy9UiX0NHTLIxGhDWVJJsc1IyCITdOF6TPbW13qB0=.27661012-247b-4e4b-bf39-b203a21dced0@github.com>
Message-ID: <YZIO-ZoQetwVQzcQnMoiKdBmcHNYfyRKyjJtqI3NGAI=.1f5f3f33-f602-4209-9d41-328bd1c05f14@github.com>

On Tue, 24 May 2022 10:47:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 1110:
>> 
>>> 1108:          * invoked {@link #join() join} (or {@link #joinUntil(Instant) joinUntil}).
>>> 1109:          * The behavior of this method is unspecified when invoking this method before
>>> 1110:          * the {@code join} is invoked.
>> 
>> Suggestion:
>> 
>>          * {@link #join} is invoked.
>
> More generally, I see that you used `{@code ... }` in a lot of places where `{@link ... }` could also be used. In some of those places (like this one) where there is a clear cross-reference, I think `@link` could be preferrable. The only case where `@code` is fine is when referring to the name of the class itself (e.g. `{@code StructuredTaskScope}`). But of course this is subjective.

Also, note the typo `the join is invoked`. Either `the` is dropped, or `method` is added. I've seen more than one occurrence of this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From alanb at openjdk.java.net  Tue May 24 11:01:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 11:01:45 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v2]
In-Reply-To: <YZIO-ZoQetwVQzcQnMoiKdBmcHNYfyRKyjJtqI3NGAI=.1f5f3f33-f602-4209-9d41-328bd1c05f14@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <zaEKOTzWmnpRf1Llw19wRkRelLnpjKjzhcNX0TkqyPY=.3295e7d7-5bb6-4526-a1f9-ed6a6ffde5c4@github.com>
 <0ImeO1neNjHytwzg3TcoZZKP_bwbK0WhxBhB6pJ9zto=.d04425d4-89d4-4c22-8747-73e00b2dc5ab@github.com>
 <RyZy9UiX0NHTLIxGhDWVJJsc1IyCITdOF6TPbW13qB0=.27661012-247b-4e4b-bf39-b203a21dced0@github.com>
 <YZIO-ZoQetwVQzcQnMoiKdBmcHNYfyRKyjJtqI3NGAI=.1f5f3f33-f602-4209-9d41-328bd1c05f14@github.com>
Message-ID: <d2s-9ImKiSvyWYK6BZ1l9_2aTDZERk-lP_Cte4AlYJ4=.4506a3ef-e0cd-4dfc-b7d6-9a8c7e9d217c@github.com>

On Tue, 24 May 2022 10:48:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> More generally, I see that you used `{@code ... }` in a lot of places where `{@link ... }` could also be used. In some of those places (like this one) where there is a clear cross-reference, I think `@link` could be preferrable. The only case where `@code` is fine is when referring to the name of the class itself (e.g. `{@code StructuredTaskScope}`). But of course this is subjective.
>
> Also, note the typo `the join is invoked`. Either `the` is dropped, or `method` is added. I've seen more than one occurrence of this.

It should be "before join is invoked". It doesn't use a link here because it already links to join and joinUntil in the previous sentence.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From aivanov at openjdk.java.net  Tue May 24 11:28:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 11:28:50 GMT
Subject: Integrated: 8284191: Replace usages of 'a the' in hotspot and
 java.base
In-Reply-To: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
References: <g7JqzoqlV9nfmJEWNbeGbEaU9lUMVg1tU5kaYJ-ONI8=.c387b652-b4db-41b8-82dc-7c5678ae5240@github.com>
Message-ID: <ZIBUrN38HimpUwfEYc-LwYC3gXjfDXNaD55bHE9PU2M=.87e99c4b-c1a3-47d4-9323-421efb88ed06@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

This pull request has now been integrated.

Changeset: e0d361ce
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e0d361cea91d3dd1450aece73f660b4abb7ce5fa
Stats:     303 lines in 162 files changed: 0 ins; 11 del; 292 mod

8284191: Replace usages of 'a the' in hotspot and java.base

Reviewed-by: lancea, wetmore, naoto, iris, kevinw, xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Tue May 24 11:39:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 11:39:50 GMT
Subject: Integrated: 8284213: Replace usages of 'a the' in xml
In-Reply-To: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
References: <ua4EzmtOBkL2UuZ2aqmTOP8IMUy1H7GTdxsirjmtojc=.6680b022-26a9-4e8d-abdb-05a76bb06304@github.com>
Message-ID: <frHC0RcLlVfNnBw52fxZRKRQIpUztmJeRWAgidedsyI=.adb264b9-f495-4c68-b5d0-1ffa3ca36b89@github.com>

On Wed, 18 May 2022 13:58:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> I tried to avoid changing external libraries, there are quite a few such typos.
> Let me know if I should revert any files.

This pull request has now been integrated.

Changeset: 5974f5fe
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5974f5fed3ef888e8e64b1bf33793a7bcc4ca77c
Stats:     17 lines in 9 files changed: 0 ins; 0 del; 17 mod

8284213: Replace usages of 'a the' in xml

Reviewed-by: lancea, dmarkov, iris, prr, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/8769

From alanb at openjdk.java.net  Tue May 24 11:47:03 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 11:47:03 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v2]
In-Reply-To: <0ImeO1neNjHytwzg3TcoZZKP_bwbK0WhxBhB6pJ9zto=.d04425d4-89d4-4c22-8747-73e00b2dc5ab@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <zaEKOTzWmnpRf1Llw19wRkRelLnpjKjzhcNX0TkqyPY=.3295e7d7-5bb6-4526-a1f9-ed6a6ffde5c4@github.com>
 <0ImeO1neNjHytwzg3TcoZZKP_bwbK0WhxBhB6pJ9zto=.d04425d4-89d4-4c22-8747-73e00b2dc5ab@github.com>
Message-ID: <p6fwK1GZ4oNeovUwy_2bIm9GhsSTAwN2lEQ6zcINj0s=.2111a125-c7f5-4cf4-85c7-733af0d54b73@github.com>

On Tue, 24 May 2022 10:52:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Alan Bateman 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 six additional commits since the last revision:
>> 
>>  - Use {@code ...}, replace task->subtask, fix typos, add jls ref
>>  - Merge
>>  - @ignore StructuredThreadDumpTest until test infra in place
>>  - Refresh
>>  - Merge
>>  - Initial commit
>
> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 214:
> 
>> 212:  * <h2><a id="TreeStructure">Tree structure</a></h2>
>> 213:  *
>> 214:  * StructuredTaskScopes form a tree where parent-child relations are established
> 
> Should we mention what happens in the owner thread completes its execution and the scope's `close` method has not been called? I think that, as discussed offline, the fact that the thread will attempt to close any nested scopes when terminating is an important aspect of this API.

The close method might be the right place for this. It has to specify that an attempt to close out of order will close the nested scopes and terminating without close is much the same. I'll see what I can do, thanks for this suggestion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From duke at openjdk.java.net  Tue May 24 12:58:45 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 24 May 2022 12:58:45 GMT
Subject: RFR: 8202449: overflow handling in Random.doubles [v3]
In-Reply-To: <6OZGdr2SP8kDv1jsxupgndb3Lsbe62CQLlvhgHZNQAo=.1777192e-ba14-4bcc-9fea-a6a06d66543b@github.com>
References: <6OZGdr2SP8kDv1jsxupgndb3Lsbe62CQLlvhgHZNQAo=.1777192e-ba14-4bcc-9fea-a6a06d66543b@github.com>
Message-ID: <S9k1SfnSYAzoiTlxdQ5fBpdMt4Uu8mlNWHSYJhWTI0g=.2e023744-7ed1-40a0-8075-31d8f2ede9ec@github.com>

> Extend the range of Random.doubles(double, double) and similar methods.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8202449: overflow handling in Random.doubles

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8791/files
  - new: https://git.openjdk.java.net/jdk/pull/8791/files/62322ac1..954d1ea2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8791&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8791&range=01-02

  Stats: 21 lines in 2 files changed: 0 ins; 8 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8791.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8791/head:pull/8791

PR: https://git.openjdk.java.net/jdk/pull/8791

From naoto at openjdk.java.net  Tue May 24 13:11:40 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 24 May 2022 13:11:40 GMT
Subject: RFR: 8287181: Avoid redundant HashMap.containsKey calls in
 InternalLocaleBuilder.setExtension
In-Reply-To: <Xzpw4lqoOLnSpSrkfIeCbh-Gq9Ru2BQpiYLuA5Wkn1o=.1f208f43-fe60-4e6c-8dcf-a23a625be047@github.com>
References: <Xzpw4lqoOLnSpSrkfIeCbh-Gq9Ru2BQpiYLuA5Wkn1o=.1f208f43-fe60-4e6c-8dcf-a23a625be047@github.com>
Message-ID: <0y1YxpBNBcJbdc6T5LsNvbdyl4hyeR0jZopfZ-OelK0=.18563cd8-5ec1-467e-ad60-5984c09c915a@github.com>

On Sat, 30 Apr 2022 17:10:55 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to separately perform `HashMap.containsKey` before `HashMap.remove` call. If key is present - it will be removed anyway. If it's not present, nothing will be deleted.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8488

From duke at openjdk.java.net  Tue May 24 13:12:58 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 24 May 2022 13:12:58 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v3]
In-Reply-To: <1XOcr-j-27aYsiJnYQ5UYUaBTO_stl-hZlnsKulgW3c=.1d384bf9-e88b-407d-9423-6dc6234025cd@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
 <Uh30nZyDeqt2ARI5Y-FXoBKabCJxYebhgaimCdixxOo=.87c7c3c5-6310-45f2-b9b8-b390052c1f9e@github.com>
 <1XOcr-j-27aYsiJnYQ5UYUaBTO_stl-hZlnsKulgW3c=.1d384bf9-e88b-407d-9423-6dc6234025cd@github.com>
Message-ID: <W1pm_d2_eCjJYnMxHG91-nMZf-N9Rq2_cr5Yu-iqSG0=.d1db4723-3108-4c0c-8c5c-c07b309a54ec@github.com>

On Tue, 24 May 2022 05:36:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> liach has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the try catch block as it doesn't throw checked exceptions
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 605:
> 
>> 603:         mv.visitLdcInsn(Type.getObjectType(dotToSlash(className)));
>> 604:         mv.visitMethodInsn(INVOKEVIRTUAL, JL_CLASS,
>> 605:                 "getClassLoader", "()" + LJL_CLASSLOADER, false);
> 
> Hello @liach, should this instead be using the (application supplied) `loader` returned by the call to `ProxyGenerator.getClassLoader()` or maybe the `loader` member in the `ProxyGenerator` itself?

This is equivalent to `jdk.proxy5.$Proxy5.class.getClassLoader()` in Java source code, so this is exactly the application-supplied loader, which also uses the same loader as the previous behavior of `forName` calls.

If you want to pass the loader from `ProxyGenerator` to the proxy, it requires complex tricks. Hidden classes won't work due to serialization incompatibility; accessor methods would be defined in `jdk.internal` and exported specifically to the proxy modules, but writing a class so each proxy gets its loader while what I wrote can already do is overkill.

> test/jdk/java/lang/reflect/Proxy/LazyInitializationTest.java line 56:
> 
>> 54: 
>> 55:         value.m(new Parameter());
>> 56:         Assert.assertTrue(initialized, "parameter type initialized after instantiation");
> 
>> "parameter type initialized after instantiation"
> 
> Since this is the text that gets displayed/reported when the assertion fails, should this instead be "parameter type not initialized"?

The rendered text for testng assert is `message expected: value actual: value`, so on a mismatch, it would print `parameter type initialized after instantiation expected: true actual: false`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8800

From shade at openjdk.java.net  Tue May 24 14:14:09 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 May 2022 14:14:09 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
Message-ID: <EQqFzl8MKu9zhRWM17twQXqSkkRhVzvp5vhlMnTC7CI=.41d6ba8a-a243-493e-82e0-e87982d8658c@github.com>

On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>>  - [x] GHA run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another release test

Thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From shade at openjdk.java.net  Tue May 24 14:14:11 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 May 2022 14:14:11 GMT
Subject: Integrated: 8287137: Problemlist failing x86_32 tests after Loom
 integration
In-Reply-To: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
Message-ID: <Uhj76EkIXsLMDEMaJaGnjwXXtupxq8vnKnDueEVcYKs=.c4c514eb-058d-47af-b98e-34023a306864@github.com>

On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
> 
> Additional testing:
>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>  - [x] GHA run

This pull request has now been integrated.

Changeset: 0a82c4eb
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a82c4ebc3748f6dfbbcd72e4421fbe0ea89e0b0
Stats:     279 lines in 3 files changed: 279 ins; 0 del; 0 mod

8287137: Problemlist failing x86_32 tests after Loom integration

Reviewed-by: prr, mcimadamore

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From mcimadamore at openjdk.java.net  Tue May 24 14:47:16 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 14:47:16 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
Message-ID: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>

Constructing indexed var handles using the `MemoryLayout` API produces `VarHandle` which do not check the input indices for out-of-bounds conditions.
While this can never result in a VM crash (after all the memory segment will protect against "true" OOB access), it is still possible for an access expression to refer to parts of a segment that are logically unrelated.

This patch adds a "logical" bound check to all indexed var handles generated using the layout API.
Benchmarks are not affected by the check. Users are still able to create custom "unchecked" var handles, using the combinator API in `MethodHandles`.

-------------

Commit messages:
 - Tweak javadoc
 - Merge branch 'master' into vh_bound_checks
 - Initial push

Changes: https://git.openjdk.java.net/jdk/pull/8868/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8868&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287244
  Stats: 73 lines in 3 files changed: 54 ins; 4 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8868.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8868/head:pull/8868

PR: https://git.openjdk.java.net/jdk/pull/8868

From mcimadamore at openjdk.java.net  Tue May 24 14:56:39 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 14:56:39 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
In-Reply-To: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
Message-ID: <ZAWw1FGxP6OMNggaV3uSGm-O84FiiWwbHkX9T1paJlA=.49a232c8-53a8-40a4-bf71-7c2acf733459@github.com>

On Tue, 24 May 2022 14:40:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Constructing indexed var handles using the `MemoryLayout` API produces `VarHandle` which do not check the input indices for out-of-bounds conditions.
> While this can never result in a VM crash (after all the memory segment will protect against "true" OOB access), it is still possible for an access expression to refer to parts of a segment that are logically unrelated.
> 
> This patch adds a "logical" bound check to all indexed var handles generated using the layout API.
> Benchmarks are not affected by the check. Users are still able to create custom "unchecked" var handles, using the combinator API in `MethodHandles`.

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 537:

> 535:          *
> 536:          * <ul>
> 537:          *    <li>if {@code F > 0}, then {@code B = ceilDiv(C - S, F)}</li>

These formulas come from the formula for computing the accessed index A:

`A = S + I * F`

And then deriving the value for I, by equating `A = C` (for F > 0) and `A = -1` (for F < 0) - that is equating the accessed index to the "first" out of bound index. `ceilDiv` ensures there is "some room" between the max/min index and the selected one.

src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 109:

> 107:         SequenceLayout seq = (SequenceLayout)layout;
> 108:         checkSequenceBounds(seq, index);
> 109:         long elemSize = seq.elementLayout().bitSize();

I've simplified the code here, as it still had traces of attempts to avoid the call to `bitSize` (this method used to be partial).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From mcimadamore at openjdk.java.net  Tue May 24 14:56:39 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 14:56:39 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
In-Reply-To: <ZAWw1FGxP6OMNggaV3uSGm-O84FiiWwbHkX9T1paJlA=.49a232c8-53a8-40a4-bf71-7c2acf733459@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <ZAWw1FGxP6OMNggaV3uSGm-O84FiiWwbHkX9T1paJlA=.49a232c8-53a8-40a4-bf71-7c2acf733459@github.com>
Message-ID: <L5oPMEW_QJEty38sEuTPB7o-p17CjdFbHVO6Azcpur8=.933582e7-88a8-4542-9c22-a813d292b69f@github.com>

On Tue, 24 May 2022 14:51:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Constructing indexed var handles using the `MemoryLayout` API produces `VarHandle` which do not check the input indices for out-of-bounds conditions.
>> While this can never result in a VM crash (after all the memory segment will protect against "true" OOB access), it is still possible for an access expression to refer to parts of a segment that are logically unrelated.
>> 
>> This patch adds a "logical" bound check to all indexed var handles generated using the layout API.
>> Benchmarks are not affected by the check. Users are still able to create custom "unchecked" var handles, using the combinator API in `MethodHandles`.
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 537:
> 
>> 535:          *
>> 536:          * <ul>
>> 537:          *    <li>if {@code F > 0}, then {@code B = ceilDiv(C - S, F)}</li>
> 
> These formulas come from the formula for computing the accessed index A:
> 
> `A = S + I * F`
> 
> And then deriving the value for I, by equating `A = C` (for F > 0) and `A = -1` (for F < 0) - that is equating the accessed index to the "first" out of bound index. `ceilDiv` ensures there is "some room" between the max/min index and the selected one.

Note also that these complex bound calculation are performed statically, when we build the layout path. When we're done, we just have an upper bound, which we can check against using `Objects.checkIndex`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From jvernee at openjdk.java.net  Tue May 24 15:07:57 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 24 May 2022 15:07:57 GMT
Subject: Integrated: 8287158: Explicitly reject unsupported call shapes on
 macos-aarch64 in mainline
In-Reply-To: <jzT8uoRxxN4ZEXD-3aFO2eLIJJYSVpw3R_gYQNls9GM=.95b5ec65-9aad-42f9-894f-598e70ad449f@github.com>
References: <jzT8uoRxxN4ZEXD-3aFO2eLIJJYSVpw3R_gYQNls9GM=.95b5ec65-9aad-42f9-894f-598e70ad449f@github.com>
Message-ID: <eCJwJ5Rjk8pesixXG4uQ1HmAnVoZrEZSCjhswwtAovM=.186cbf14-b7ed-4d67-96bc-4fcd906db574@github.com>

On Mon, 23 May 2022 12:27:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Bring in changes from the panama-foreign repo
> 
> These changes pertain to explicitly rejecting unsupported call shapes on macos-aarch64.
> 
> Original PRs:
> 1. https://github.com/openjdk/panama-foreign/pull/676
> 2. https://github.com/openjdk/panama-foreign/pull/677
> 
> Testing: `jdk_foreign` on linux-aarch64-debug, macosx-aarch64-debug, linux-x64-debug, macosx-x64-debug, and windows-x64-debug

This pull request has now been integrated.

Changeset: 8f0eb5d4
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8f0eb5d40178b49fa69a623d057ca00846526319
Stats:     25411 lines in 18 files changed: 719 ins; 24633 del; 59 mod

8287158: Explicitly reject unsupported call shapes on macos-aarch64 in mainline

Reviewed-by: mcimadamore, ngasson

-------------

PR: https://git.openjdk.java.net/jdk/pull/8842

From alanb at openjdk.java.net  Tue May 24 15:15:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 May 2022 15:15:43 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v3]
In-Reply-To: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
Message-ID: <WB-jlVcwVv0n9Ut4s8w6a20X-P-qJFIYmxd1DOfau9Y=.665df86a-d1f7-4936-b08c-a2591af44017@github.com>

> This is the implementation of JEP 428: Structured Concurrency (Incubator).
> 
> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Add statement to close about thread termination

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8787/files
  - new: https://git.openjdk.java.net/jdk/pull/8787/files/c72f0330..4fc454a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8787&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8787&range=01-02

  Stats: 12 lines in 3 files changed: 5 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8787/head:pull/8787

PR: https://git.openjdk.java.net/jdk/pull/8787

From rriggs at openjdk.java.net  Tue May 24 15:16:04 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 24 May 2022 15:16:04 GMT
Subject: RFR: 8287181: Avoid redundant HashMap.containsKey calls in
 InternalLocaleBuilder.setExtension
In-Reply-To: <Xzpw4lqoOLnSpSrkfIeCbh-Gq9Ru2BQpiYLuA5Wkn1o=.1f208f43-fe60-4e6c-8dcf-a23a625be047@github.com>
References: <Xzpw4lqoOLnSpSrkfIeCbh-Gq9Ru2BQpiYLuA5Wkn1o=.1f208f43-fe60-4e6c-8dcf-a23a625be047@github.com>
Message-ID: <QvvJd06u-nKLOpGX0gfmtv8tbFrUBC4xh5BmWsjkUkI=.3267c0e3-de0d-40f1-8573-5296237fc62b@github.com>

On Sat, 30 Apr 2022 17:10:55 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to separately perform `HashMap.containsKey` before `HashMap.remove` call. If key is present - it will be removed anyway. If it's not present, nothing will be deleted.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8488

From mcimadamore at openjdk.java.net  Tue May 24 15:28:27 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 15:28:27 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v2]
In-Reply-To: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
Message-ID: <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>

> Constructing indexed var handles using the `MemoryLayout` API produces `VarHandle` which do not check the input indices for out-of-bounds conditions.
> While this can never result in a VM crash (after all the memory segment will protect against "true" OOB access), it is still possible for an access expression to refer to parts of a segment that are logically unrelated.
> 
> This patch adds a "logical" bound check to all indexed var handles generated using the layout API.
> Benchmarks are not affected by the check. Users are still able to create custom "unchecked" var handles, using the combinator API in `MethodHandles`.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak javadoc for ValueLayout::arrayElementVarHandle

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8868/files
  - new: https://git.openjdk.java.net/jdk/pull/8868/files/453392ae..a682cc03

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8868&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8868&range=00-01

  Stats: 17 lines in 1 file changed: 16 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8868.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8868/head:pull/8868

PR: https://git.openjdk.java.net/jdk/pull/8868

From lancea at openjdk.java.net  Tue May 24 15:59:55 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 24 May 2022 15:59:55 GMT
Subject: Integrated: 8287162: (zipfs) Performance regression related to support
 for POSIX file permissions
In-Reply-To: <znseZkEwQfyr0ih8UtE3cxNsXelAnN2pULr5Tj-oq6o=.35ca3a29-097b-4d1a-a3ff-52a5ca83c2c1@github.com>
References: <znseZkEwQfyr0ih8UtE3cxNsXelAnN2pULr5Tj-oq6o=.35ca3a29-097b-4d1a-a3ff-52a5ca83c2c1@github.com>
Message-ID: <d-CrwLZR-v_sKDAiN4WMb28pqIn54Zj1Z5eKcagZ0U0=.01d04a4f-7c17-4ba6-86fa-dee088aa699e@github.com>

On Mon, 23 May 2022 19:47:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi all,
> 
> This PR addresses the performance issue that is described in JDK-8287162.
> 
> With this fix,  the ZipFileSystem methods:  initOwner, initGroup, and initPermissions will not be invoked unless enablePosixFileAttributes=true.  
> 
> Mach5 tiers1-3 are currently running and have not encountered any issues.

This pull request has now been integrated.

Changeset: a10c5597
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a10c5597d93c4402bafdbb570437aac052b10027
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8287162: (zipfs) Performance regression related to support for POSIX file permissions

Reviewed-by: jpai, alanb, clanger

-------------

PR: https://git.openjdk.java.net/jdk/pull/8854

From darcy at openjdk.java.net  Tue May 24 16:06:06 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 24 May 2022 16:06:06 GMT
Subject: RFR: 8287206: Use WrongThreadException for confinement errors
In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
Message-ID: <lbYfxORTmX4RuLP4lqTL_XLVS7HN4miGCW6eOYpfMQo=.a6a2458a-b339-4748-b04f-6d08010bebbe@github.com>

On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8865

From iklam at openjdk.java.net  Tue May 24 16:15:03 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 24 May 2022 16:15:03 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v2]
In-Reply-To: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
Message-ID: <Ep6v5vDnXI4JIaR1xNn-Fmdj_l_-4WFkBLPqlArY9eI=.e9babec6-3e1a-4152-88b6-4a8fdbe83fa9@github.com>

> This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode.
> 
> The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1).
> 
> However, the "hybrid checks" only considers the following controllers that Java cares about:
> 
> - cpu
> - cpuacct
> - cpuset
> - blkio
> - memory
> - pids
> 
> If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert.
> 
> 
> $ cat /proc/self/cgroup
> 1:freezer:/
> 0::/user.slice/user-1001.slice/session-85.scope
> 
> 
> The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @jerboaa comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8858/files
  - new: https://git.openjdk.java.net/jdk/pull/8858/files/c4d8354d..1f17b6e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8858.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8858/head:pull/8858

PR: https://git.openjdk.java.net/jdk/pull/8858

From iklam at openjdk.java.net  Tue May 24 16:15:06 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 24 May 2022 16:15:06 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v2]
In-Reply-To: <EisSyVHbjSUIyBsszUjM97_OwD8Jt2cBIzSpXZpAEu8=.c62a5c40-e727-4f27-96d5-c7e5087725f0@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
 <EisSyVHbjSUIyBsszUjM97_OwD8Jt2cBIzSpXZpAEu8=.c62a5c40-e727-4f27-96d5-c7e5087725f0@github.com>
Message-ID: <ddUidECANrWtWa9L99eKLekZaltBGZh07WPdZwadEpI=.adb52b74-6624-4b1f-bf7b-a62aef5b9aeb@github.com>

On Tue, 24 May 2022 10:12:31 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @jerboaa comments
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 155:
> 
>> 153:                 // There are some controllers (such as freezer) that Java doesn't
>> 154:                 // care about. Just ignore them. These are not considered in the
>> 155:                 // anyCgroupsV1Controller/anyCgroupsV1Controller checks.
> 
> It's not clear why this `default` is necessary. Could we just add the comment like so:
> 
> 
> // Intentional fall-through. There are controllers (such as freezer) that
> // Java doesn't care about. Just ignore them. Only listed controllers are
> // considered in the anyCgroupsV1Controller/anyCgroupsV2Controller checks.

This is not a fall-through because the previous line ends with a `break`.

> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 229:
> 
>> 227:         String name = tokens[1];
>> 228:         if (!name.equals("")) {
>> 229:             // This is probably a v1 controller that we have ignored (e.g., freezer)
> 
> Could we add an assertion that the controller isn't in the `infos` map?
> 
>            if (!name.equals("")) {
>             // This must be a v1 controller that we have ignored (e.g., freezer)
>             assert infos.get(name) == null;
>             return;
>          }

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From duke at openjdk.java.net  Tue May 24 16:23:59 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Tue, 24 May 2022 16:23:59 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults [v2]
In-Reply-To: <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>
Message-ID: <VGrkEpk7hbAhaeMsUEhe7zyf_2Z5MeCvJvyEfUxhIbk=.3d23b9a4-7b40-4285-8669-bf82c0242ae6@github.com>

On Mon, 23 May 2022 18:58:34 GMT, Mark Powers <duke at openjdk.java.net> wrote:

>> JDK-6725221 Standardize obtaining boolean properties with defaults
>
> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Alan and Jamil comments
>  - Merge
>  - reverse true.equals and false.equals changes
>  - Merge
>  - Merge
>  - first iteration

Mach5 tier1 and tier2 completed without any failures. I don't know what to make of the pre-submit failures - lang and hotspot?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8559

From psandoz at openjdk.java.net  Tue May 24 16:26:27 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 24 May 2022 16:26:27 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v2]
In-Reply-To: <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>
Message-ID: <YifMqnR2TNoI1L20rccCFJ2sIWWM6rdxBybxLOiqnQY=.a59e5ad1-0107-42a1-8b6f-03c4fb62f226@github.com>

On Tue, 24 May 2022 15:28:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Constructing indexed var handles using the `MemoryLayout` API produces `VarHandle` which do not check the input indices for out-of-bounds conditions.
>> While this can never result in a VM crash (after all the memory segment will protect against "true" OOB access), it is still possible for an access expression to refer to parts of a segment that are logically unrelated.
>> 
>> This patch adds a "logical" bound check to all indexed var handles generated using the layout API.
>> Benchmarks are not affected by the check. Users are still able to create custom "unchecked" var handles, using the combinator API in `MethodHandles`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc for ValueLayout::arrayElementVarHandle

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 374:

> 372:      *
> 373:      * Additionally, the provided dynamic values must conform to some bound which is derived from the layout path, that is,
> 374:      * {@code 0 <= x_i <= b_i}, where {@code 0 <= i <= n}, or {@link IndexOutOfBoundsException} is thrown.

Suggestion:

     * {@code 0 <= x_i < b_i}, where {@code 1 <= i <= n}, or {@link IndexOutOfBoundsException} is thrown.

We refer later to `B` being an exclusive upper bound (computed using `ceilDiv`).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From asemenyuk at openjdk.java.net  Tue May 24 16:36:59 2022
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 24 May 2022 16:36:59 GMT
Subject: Integrated: 8281682: Redundant .ico files in Windows app-image cause
 unnecessary bloat
In-Reply-To: <i1lsikErMof0IvPkgfxYiOCOaAMuS3P1EOKj21ulDw4=.7d7d5610-0ca7-459c-9eef-5e506de5be23@github.com>
References: <i1lsikErMof0IvPkgfxYiOCOaAMuS3P1EOKj21ulDw4=.7d7d5610-0ca7-459c-9eef-5e506de5be23@github.com>
Message-ID: <VOcuWCHLG6lUAA02sJE-G9kdYYhCTiGLSyUatJODIs8=.6823b095-6f8f-47e2-80f6-9ef0e1257eb4@github.com>

On Thu, 19 May 2022 19:13:12 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8281682: Redundant .ico files in Windows app-image cause unnecessary bloat

This pull request has now been integrated.

Changeset: 45180633
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45180633d34b6cbb679bae0753d9f422e76d6297
Stats:     169 lines in 8 files changed: 150 ins; 6 del; 13 mod

8281682: Redundant .ico files in Windows app-image cause unnecessary bloat

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.java.net/jdk/pull/8794

From psandoz at openjdk.java.net  Tue May 24 16:52:59 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 24 May 2022 16:52:59 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v2]
In-Reply-To: <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>
Message-ID: <i2bEdCYejPQxvtCHHR7XdM4hhfFSxWnu-EuPOHOhxA0=.12f3d453-f7cd-4eb9-b6ef-eb47d9f8ca96@github.com>

On Tue, 24 May 2022 15:28:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Constructing indexed var handles using the `MemoryLayout` API produces `VarHandle` which do not check the input indices for out-of-bounds conditions.
>> While this can never result in a VM crash (after all the memory segment will protect against "true" OOB access), it is still possible for an access expression to refer to parts of a segment that are logically unrelated.
>> 
>> This patch adds a "logical" bound check to all indexed var handles generated using the layout API.
>> Benchmarks are not affected by the check. Users are still able to create custom "unchecked" var handles, using the combinator API in `MethodHandles`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc for ValueLayout::arrayElementVarHandle

src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java line 256:

> 254:     private long[] addBound(long maxIndex) {
> 255:         long[] newBounds = new long[bounds.length + 1];
> 256:         System.arraycopy(bounds, 0, newBounds, 0, bounds.length);

Suggestion:

        long[] newBounds = Arrays.copyOf(bounds, bounds.length + 1);

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From rriggs at openjdk.java.net  Tue May 24 17:29:03 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 24 May 2022 17:29:03 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v2]
In-Reply-To: <wzjh1NqTjoYU3FN8Vu2vlofpf_9gL-T9rCs0cQDPLUM=.d29d7d63-2aeb-4f06-b365-499c8b9bfceb@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <wzjh1NqTjoYU3FN8Vu2vlofpf_9gL-T9rCs0cQDPLUM=.d29d7d63-2aeb-4f06-b365-499c8b9bfceb@github.com>
Message-ID: <T1cgxeczSkx9ejS9ZcIDtGXPuCATMESMn4WuUOfbkYc=.bfbf3601-1d6a-4b0b-86a5-f2fc4918d5be@github.com>

On Fri, 20 May 2022 22:18:42 GMT, liach <duke at openjdk.java.net> wrote:

>> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert PrimitiveTypeInfo to an enum

Looks good.

Did you consider switch (class) {...} in PrimitiveTypeInfo.get?  
The `if` cascade may be quicker given the expected distribution of lookups.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8801

From mcimadamore at openjdk.java.net  Tue May 24 17:46:04 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 17:46:04 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v2]
In-Reply-To: <YifMqnR2TNoI1L20rccCFJ2sIWWM6rdxBybxLOiqnQY=.a59e5ad1-0107-42a1-8b6f-03c4fb62f226@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>
 <YifMqnR2TNoI1L20rccCFJ2sIWWM6rdxBybxLOiqnQY=.a59e5ad1-0107-42a1-8b6f-03c4fb62f226@github.com>
Message-ID: <8zPFIXw59l17NM33t60Vw8svVi2sa28Sr9ezN8PV4J0=.88697ee7-8f55-4598-954e-1288f8015fe4@github.com>

On Tue, 24 May 2022 16:23:52 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak javadoc for ValueLayout::arrayElementVarHandle
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 374:
> 
>> 372:      *
>> 373:      * Additionally, the provided dynamic values must conform to some bound which is derived from the layout path, that is,
>> 374:      * {@code 0 <= x_i <= b_i}, where {@code 0 <= i <= n}, or {@link IndexOutOfBoundsException} is thrown.
> 
> Suggestion:
> 
>      * {@code 0 <= x_i < b_i}, where {@code 1 <= i <= n}, or {@link IndexOutOfBoundsException} is thrown.
> 
> We refer later to `B` being an exclusive upper bound (computed using `ceilDiv`).

Indices start at zero. The ceilDiv operation is needed so that the operation returns the first index outisde the range (it's a bit subtle, sorry, but I don't know how else to express).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From mcimadamore at openjdk.java.net  Tue May 24 17:58:04 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 17:58:04 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v2]
In-Reply-To: <8zPFIXw59l17NM33t60Vw8svVi2sa28Sr9ezN8PV4J0=.88697ee7-8f55-4598-954e-1288f8015fe4@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>
 <YifMqnR2TNoI1L20rccCFJ2sIWWM6rdxBybxLOiqnQY=.a59e5ad1-0107-42a1-8b6f-03c4fb62f226@github.com>
 <8zPFIXw59l17NM33t60Vw8svVi2sa28Sr9ezN8PV4J0=.88697ee7-8f55-4598-954e-1288f8015fe4@github.com>
Message-ID: <3WFoOGtyvPPOlWK9wXKLTNPuBNs40STh2HAZZAmoo5I=.45107bad-8726-42e2-8120-8c4fff367069@github.com>

On Tue, 24 May 2022 17:43:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 374:
>> 
>>> 372:      *
>>> 373:      * Additionally, the provided dynamic values must conform to some bound which is derived from the layout path, that is,
>>> 374:      * {@code 0 <= x_i <= b_i}, where {@code 0 <= i <= n}, or {@link IndexOutOfBoundsException} is thrown.
>> 
>> Suggestion:
>> 
>>      * {@code 0 <= x_i < b_i}, where {@code 1 <= i <= n}, or {@link IndexOutOfBoundsException} is thrown.
>> 
>> We refer later to `B` being an exclusive upper bound (computed using `ceilDiv`).
>
> Indices start at zero. The ceilDiv operation is needed so that the operation returns the first index outisde the range (it's a bit subtle, sorry, but I don't know how else to express).

Here's a concrete example:

Consider a sequence layout with 6 elements. Then:

element count = 6
valid indices 0, 1, 2, 3, 4, 5

Now consider a var handle that is obtained by calling the path element method, passing the following parameters

start = 1
step = 2

This sets up the following mapping between logical an physical indices:

0 -> 1
1 -> 3
2 -> 5

Where on the LHS we have the logical index (the one passed to the VH) and on the RHS we have the actual index it is translated to.

Note that the index map has three elements. So the upper bound (exclusive) of the index map is 3 - that is, we can pass indices 0, 1, 2.

According to the formula shown in the javadoc:

B = ceilDiv((elementCount - start) / step);

so:

B = ceilDiv((6 - 1) / 2)
    = ceilDiv(5 / 2)

Note how, w/o ceilDiv we'd get 2 (the last valid index), and not 3 (the first invalid index).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From psandoz at openjdk.java.net  Tue May 24 17:58:04 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 24 May 2022 17:58:04 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v2]
In-Reply-To: <3WFoOGtyvPPOlWK9wXKLTNPuBNs40STh2HAZZAmoo5I=.45107bad-8726-42e2-8120-8c4fff367069@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>
 <YifMqnR2TNoI1L20rccCFJ2sIWWM6rdxBybxLOiqnQY=.a59e5ad1-0107-42a1-8b6f-03c4fb62f226@github.com>
 <8zPFIXw59l17NM33t60Vw8svVi2sa28Sr9ezN8PV4J0=.88697ee7-8f55-4598-954e-1288f8015fe4@github.com>
 <3WFoOGtyvPPOlWK9wXKLTNPuBNs40STh2HAZZAmoo5I=.45107bad-8726-42e2-8120-8c4fff367069@github.com>
Message-ID: <kVFK0fzk6TfoSDbdKddlhuASkFEojp7I8jJe2SZCnNM=.6a980200-5d27-4a37-9068-8a7394ce53c3@github.com>

On Tue, 24 May 2022 17:53:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Indices start at zero. The ceilDiv operation is needed so that the operation returns the first index outisde the range (it's a bit subtle, sorry, but I don't know how else to express).
>
> Here's a concrete example:
> 
> Consider a sequence layout with 6 elements. Then:
> 
> element count = 6
> valid indices 0, 1, 2, 3, 4, 5
> 
> Now consider a var handle that is obtained by calling the path element method, passing the following parameters
> 
> start = 1
> step = 2
> 
> This sets up the following mapping between logical an physical indices:
> 
> 0 -> 1
> 1 -> 3
> 2 -> 5
> 
> Where on the LHS we have the logical index (the one passed to the VH) and on the RHS we have the actual index it is translated to.
> 
> Note that the index map has three elements. So the upper bound (exclusive) of the index map is 3 - that is, we can pass indices 0, 1, 2.
> 
> According to the formula shown in the javadoc:
> 
> B = ceilDiv((elementCount - start) / step);
> 
> so:
> 
> B = ceilDiv((6 - 1) / 2)
>     = ceilDiv(5 / 2)
> 
> Note how, w/o ceilDiv we'd get 2 (the last valid index), and not 3 (the first invalid index).

The terms `x_1, x_2, ... x__n` are defined, but `x_0` is not. 

I think you can refer to the first index out of bounds as the exclusive upper bound of the range?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From psandoz at openjdk.java.net  Tue May 24 18:06:55 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 24 May 2022 18:06:55 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v2]
In-Reply-To: <kVFK0fzk6TfoSDbdKddlhuASkFEojp7I8jJe2SZCnNM=.6a980200-5d27-4a37-9068-8a7394ce53c3@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>
 <YifMqnR2TNoI1L20rccCFJ2sIWWM6rdxBybxLOiqnQY=.a59e5ad1-0107-42a1-8b6f-03c4fb62f226@github.com>
 <8zPFIXw59l17NM33t60Vw8svVi2sa28Sr9ezN8PV4J0=.88697ee7-8f55-4598-954e-1288f8015fe4@github.com>
 <3WFoOGtyvPPOlWK9wXKLTNPuBNs40STh2HAZZAmoo5I=.45107bad-8726-42e2-8120-8c4fff367069@github.com>
 <kVFK0fzk6TfoSDbdKddlhuASkFEojp7I8jJe2SZCnNM=.6a980200-5d27-4a37-9068-8a7394ce53c3@github.com>
Message-ID: <aGyTW2eKP5sxEuiBavouJ8oG11I6mlYeyyXeachJW4k=.3b9290e0-eadf-4b5b-a2f6-4a0fdcd424d8@github.com>

On Tue, 24 May 2022 17:55:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Here's a concrete example:
>> 
>> Consider a sequence layout with 6 elements. Then:
>> 
>> element count = 6
>> valid indices 0, 1, 2, 3, 4, 5
>> 
>> Now consider a var handle that is obtained by calling the path element method, passing the following parameters
>> 
>> start = 1
>> step = 2
>> 
>> This sets up the following mapping between logical an physical indices:
>> 
>> 0 -> 1
>> 1 -> 3
>> 2 -> 5
>> 
>> Where on the LHS we have the logical index (the one passed to the VH) and on the RHS we have the actual index it is translated to.
>> 
>> Note that the index map has three elements. So the upper bound (exclusive) of the index map is 3 - that is, we can pass indices 0, 1, 2.
>> 
>> According to the formula shown in the javadoc:
>> 
>> B = ceilDiv((elementCount - start) / step);
>> 
>> so:
>> 
>> B = ceilDiv((6 - 1) / 2)
>>     = ceilDiv(5 / 2)
>> 
>> Note how, w/o ceilDiv we'd get 2 (the last valid index), and not 3 (the first invalid index).
>
> The terms `x_1, x_2, ... x__n` are defined, but `x_0` is not. 
> 
> I think you can refer to the first index out of bounds as the exclusive upper bound of the range?

Sorry i misread the text, we are talking about the same thing. I think it would be clearer to refer `x_i` being in the range of `0` (inclusive) and `b_i` (exclusive), otherwise an .... is thrown. That way in subsequent doc on other methods in matches with `B`, which is exclusive.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From mcimadamore at openjdk.java.net  Tue May 24 18:06:55 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 18:06:55 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v2]
In-Reply-To: <aGyTW2eKP5sxEuiBavouJ8oG11I6mlYeyyXeachJW4k=.3b9290e0-eadf-4b5b-a2f6-4a0fdcd424d8@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>
 <YifMqnR2TNoI1L20rccCFJ2sIWWM6rdxBybxLOiqnQY=.a59e5ad1-0107-42a1-8b6f-03c4fb62f226@github.com>
 <8zPFIXw59l17NM33t60Vw8svVi2sa28Sr9ezN8PV4J0=.88697ee7-8f55-4598-954e-1288f8015fe4@github.com>
 <3WFoOGtyvPPOlWK9wXKLTNPuBNs40STh2HAZZAmoo5I=.45107bad-8726-42e2-8120-8c4fff367069@github.com>
 <kVFK0fzk6TfoSDbdKddlhuASkFEojp7I8jJe2SZCnNM=.6a980200-5d27-4a37-9068-8a7394ce53c3@github.com>
 <aGyTW2eKP5sxEuiBavouJ8oG11I6mlYeyyXeachJW4k=.3b9290e0-eadf-4b5b-a2f6-4a0fdcd424d8@github.com>
Message-ID: <GovkXtao2OtEHmRkKynWckgX_E5fDLZXKe1ji9e9P5o=.f56d4fed-a227-42e1-b3f3-a7bf15e5770c@github.com>

On Tue, 24 May 2022 18:00:46 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> The terms `x_1, x_2, ... x__n` are defined, but `x_0` is not. 
>> 
>> I think you can refer to the first index out of bounds as the exclusive upper bound of the range?
>
> Sorry i misread the text, we are talking about the same thing. I think it would be clearer to refer `x_i` being in the range of `0` (inclusive) and `b_i` (exclusive), otherwise an .... is thrown. That way in subsequent doc on other methods in matches with `B`, which is exclusive.

yes, but that seems to affect this statement:


`0 <= x_i <= b_i, where 0 <= i <= n`, or IndexOutOfBoundsException is thrown.

So we can replace with


0 <= x_i < b_i, where 1 <= i <= n`, or IndexOutOfBoundsException is thrown.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From wetmore at openjdk.java.net  Tue May 24 18:14:56 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 24 May 2022 18:14:56 GMT
Subject: RFR: JDK-6725221 Standardize obtaining boolean properties with
 defaults [v2]
In-Reply-To: <VGrkEpk7hbAhaeMsUEhe7zyf_2Z5MeCvJvyEfUxhIbk=.3d23b9a4-7b40-4285-8669-bf82c0242ae6@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
 <inA_LCRxYk4IkWZNJMC9z-sVLeBjgZEtuSGcs395jZQ=.d3de99b9-c3ff-4b3d-84c5-2f346e0ba9c0@github.com>
 <VGrkEpk7hbAhaeMsUEhe7zyf_2Z5MeCvJvyEfUxhIbk=.3d23b9a4-7b40-4285-8669-bf82c0242ae6@github.com>
Message-ID: <WJhempLMMPfk9itHCiG2ZNOiZ1u7hHtd2u4a7kRfNTg=.aac25009-2b01-4f0b-9142-f4d251f57aec@github.com>

On Tue, 24 May 2022 16:20:10 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> Mach5 tier1 and tier2 completed without any failures. I don't know what to make of the pre-submit failures - lang and hotspot?

IIUC, these are due to Loom failures in some of the other platforms supported by OpenJDK but not by Oracle.  They are being resolved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8559

From mcimadamore at openjdk.java.net  Tue May 24 18:15:45 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 18:15:45 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v3]
In-Reply-To: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
Message-ID: <UnFG9eqceJSeNXMvCzHwf4SmJb6t9yo6ZToIOdh8H8o=.ee018132-d395-466b-995a-2dd28b0e67b9@github.com>

> Constructing indexed var handles using the `MemoryLayout` API produces `VarHandle` which do not check the input indices for out-of-bounds conditions.
> While this can never result in a VM crash (after all the memory segment will protect against "true" OOB access), it is still possible for an access expression to refer to parts of a segment that are logically unrelated.
> 
> This patch adds a "logical" bound check to all indexed var handles generated using the layout API.
> Benchmarks are not affected by the check. Users are still able to create custom "unchecked" var handles, using the combinator API in `MethodHandles`.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8868/files
  - new: https://git.openjdk.java.net/jdk/pull/8868/files/a682cc03..66cf582a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8868&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8868&range=01-02

  Stats: 7 lines in 2 files changed: 1 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8868.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8868/head:pull/8868

PR: https://git.openjdk.java.net/jdk/pull/8868

From mcimadamore at openjdk.java.net  Tue May 24 18:15:45 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 May 2022 18:15:45 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v2]
In-Reply-To: <GovkXtao2OtEHmRkKynWckgX_E5fDLZXKe1ji9e9P5o=.f56d4fed-a227-42e1-b3f3-a7bf15e5770c@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <HzfMZQb4LqF4rULgI2v8kmEuMAKfSG0D-spksmlJYo8=.7fa5d0bf-83ec-45da-8631-fa819c0b9c0e@github.com>
 <YifMqnR2TNoI1L20rccCFJ2sIWWM6rdxBybxLOiqnQY=.a59e5ad1-0107-42a1-8b6f-03c4fb62f226@github.com>
 <8zPFIXw59l17NM33t60Vw8svVi2sa28Sr9ezN8PV4J0=.88697ee7-8f55-4598-954e-1288f8015fe4@github.com>
 <3WFoOGtyvPPOlWK9wXKLTNPuBNs40STh2HAZZAmoo5I=.45107bad-8726-42e2-8120-8c4fff367069@github.com>
 <kVFK0fzk6TfoSDbdKddlhuASkFEojp7I8jJe2SZCnNM=.6a980200-5d27-4a37-9068-8a7394ce53c3@github.com>
 <aGyTW2eKP5sxEuiBavouJ8oG11I6mlYeyyXeachJW4k=.3b9290e0-eadf-4b5b-a2f6-4a0fdcd424d8@github.com>
 <GovkXtao2OtEHmRkKynWckgX_E5fDLZXKe1ji9e9P5o=.f56d4fed-a227-42e1-b3f3-a7bf15e5770c@github.com>
Message-ID: <R0xpF2rA8qRqPyDf2bxAooP8M1AiuGoasZl4jiAUWmw=.17171ce5-2aed-4e01-840d-03fa43d61431@github.com>

On Tue, 24 May 2022 18:02:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Sorry i misread the text, we are talking about the same thing. I think it would be clearer to refer `x_i` being in the range of `0` (inclusive) and `b_i` (exclusive), otherwise an .... is thrown. That way in subsequent doc on other methods in matches with `B`, which is exclusive.
>
> yes, but that seems to affect this statement:
> 
> 
> `0 <= x_i <= b_i, where 0 <= i <= n`, or IndexOutOfBoundsException is thrown.
> 
> So we can replace with
> 
> 
> 0 <= x_i < b_i, where 1 <= i <= n`, or IndexOutOfBoundsException is thrown.

> Sorry i misread the text, we are talking about the same thing. I think it would be clearer to refer `x_i` being in the range of `0` (inclusive) and `b_i` (exclusive), otherwise an .... is thrown. That way in subsequent doc on other methods in matches with `B`, which is exclusive.

I apologize too - I misread your original question and thought it was about the use of ceilDiv :-) - anyway, at least that prodded me to come up with an example that explains why the logic is the way it is :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From duke at openjdk.java.net  Tue May 24 18:20:00 2022
From: duke at openjdk.java.net (Mark Powers)
Date: Tue, 24 May 2022 18:20:00 GMT
Subject: Integrated: JDK-6725221 Standardize obtaining boolean properties with
 defaults
In-Reply-To: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
References: <zE8kU9ARL-ZVE0QpViug9zZoZV8Wejy2RpA3cOe20Tc=.f74da749-7c5d-442d-9fba-43e74ba1451b@github.com>
Message-ID: <6NZWhFHhhJI3m2-DVm8Jzfla_Z7hPbnhGf4H8cBpM6c=.9e3988f9-cefd-4399-9e83-6ef6ae5ad29e@github.com>

On Thu, 5 May 2022 16:49:07 GMT, Mark Powers <duke at openjdk.java.net> wrote:

> JDK-6725221 Standardize obtaining boolean properties with defaults

This pull request has now been integrated.

Changeset: 6cc4bb11
Author:    Mark Powers <mark.powers at oracle.com>
Committer: Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6cc4bb1169f34bc091cad3e2deec37cd5585e8d5
Stats:     9 lines in 3 files changed: 1 ins; 1 del; 7 mod

6725221: Standardize obtaining boolean properties with defaults

Reviewed-by: prr, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8559

From psandoz at openjdk.java.net  Tue May 24 18:20:00 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 24 May 2022 18:20:00 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v3]
In-Reply-To: <UnFG9eqceJSeNXMvCzHwf4SmJb6t9yo6ZToIOdh8H8o=.ee018132-d395-466b-995a-2dd28b0e67b9@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <UnFG9eqceJSeNXMvCzHwf4SmJb6t9yo6ZToIOdh8H8o=.ee018132-d395-466b-995a-2dd28b0e67b9@github.com>
Message-ID: <CzsP4YlkypaYgW6Ab5Qk9Q-3D5L5RDju3GIxmWq2MpY=.d22db66e-2e5e-4976-8b99-c7e9b556f34d@github.com>

On Tue, 24 May 2022 18:15:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Constructing indexed var handles using the `MemoryLayout` API produces `VarHandle` which do not check the input indices for out-of-bounds conditions.
>> While this can never result in a VM crash (after all the memory segment will protect against "true" OOB access), it is still possible for an access expression to refer to parts of a segment that are logically unrelated.
>> 
>> This patch adds a "logical" bound check to all indexed var handles generated using the layout API.
>> Benchmarks are not affected by the check. Users are still able to create custom "unchecked" var handles, using the combinator API in `MethodHandles`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From mchung at openjdk.java.net  Tue May 24 19:01:57 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 24 May 2022 19:01:57 GMT
Subject: RFR: 8287206: Use WrongThreadException for confinement errors
In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
Message-ID: <JxNCimmAVuNOCcWFmKxr5exG_VECYNeCIrS91pvNh28=.c8c36891-e8cd-4a71-8d74-01cdf2b2b12c@github.com>

On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8865

From lmesnik at openjdk.java.net  Tue May 24 20:00:26 2022
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 24 May 2022 20:00:26 GMT
Subject: RFR: 8287200: Test
 java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java timed out after
 JDK-8287103
Message-ID: <j7f69EZ9TIIYywGBu7DIGVzw5ljS0NXBbEc7T1vlpfs=.c6238afe-baac-459d-8b7b-8f9c88207cf7@github.com>

Need to use proper synchronization.

The CyclicBarriers might move the thread to WAITING state but not BLOCKED. So it should not confuse existing checks.

-------------

Commit messages:
 - 8287200

Changes: https://git.openjdk.java.net/jdk/pull/8874/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8874&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287200
  Stats: 9 lines in 1 file changed: 4 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8874.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8874/head:pull/8874

PR: https://git.openjdk.java.net/jdk/pull/8874

From aivanov at openjdk.java.net  Tue May 24 20:12:09 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 20:12:09 GMT
Subject: Integrated: 8284209: Replace remaining usages of 'a the' in source
 code
In-Reply-To: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
References: <ewmTp7ccQjOPMRtn1liuiPkStFACC1nyQeM6kTzjFFg=.1671b250-90fb-47f9-90dc-1828e316c4a8@github.com>
Message-ID: <JXgQy5enWm0flv2yyi6KK36WsHpPuZHj8uhkz_P13H0=.b9d1bc0a-ad41-416a-ab60-22c8271b9413@github.com>

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

This pull request has now been integrated.

Changeset: 9b7e42c0
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9b7e42c0f078db778dda1011d85cd92e3e4eb979
Stats:     74 lines in 40 files changed: 0 ins; 2 del; 72 mod

8284209: Replace remaining usages of 'a the' in source code

Reviewed-by: lancea, wetmore, dfuchs, iris, jjg, ihse

-------------

PR: https://git.openjdk.java.net/jdk/pull/8771

From duke at openjdk.java.net  Tue May 24 20:31:14 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 24 May 2022 20:31:14 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v13]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <anCQlKyirNylArfOJieiaCxDlsOSAFclOcSB88y17Jk=.4ab9116d-a380-4d75-8e0c-894be695ff57@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  rename function skipBufferReference to skipBuffer

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/fbc24743..580a542c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=11-12

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue May 24 20:31:17 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 24 May 2022 20:31:17 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v12]
In-Reply-To: <QTDlYzqFPN4YaLgUFr7zY6yHyxBjCl0xHAqtJxduMf0=.5164328a-3833-4f5d-b54c-cdbe6ce7a04a@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <klI6NyXEyt_6yk0qlFaL0rsgczPFy5VNqsq5t0SlAmM=.947091f7-c3f0-49c6-b241-f2c1f2b9ff98@github.com>
 <QTDlYzqFPN4YaLgUFr7zY6yHyxBjCl0xHAqtJxduMf0=.5164328a-3833-4f5d-b54c-cdbe6ce7a04a@github.com>
Message-ID: <Y0jzY7WrZdJ23IJpKFCKXagej5O_m3aT4zc9DnIiM4A=.2d5b6a08-471e-4bad-a442-adab908b8d69@github.com>

On Fri, 20 May 2022 21:05:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add documents
>
> src/java.base/share/classes/java/io/InputStream.java line 75:
> 
>> 73:      * @return the byte array.
>> 74:      */
>> 75:     private byte[] skipBufferReference(int size) {
> 
> The method name would match the return value better if named `skipBuffer(size)`.

done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue May 24 20:32:33 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 24 May 2022 20:32:33 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v12]
In-Reply-To: <QTDlYzqFPN4YaLgUFr7zY6yHyxBjCl0xHAqtJxduMf0=.5164328a-3833-4f5d-b54c-cdbe6ce7a04a@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <klI6NyXEyt_6yk0qlFaL0rsgczPFy5VNqsq5t0SlAmM=.947091f7-c3f0-49c6-b241-f2c1f2b9ff98@github.com>
 <QTDlYzqFPN4YaLgUFr7zY6yHyxBjCl0xHAqtJxduMf0=.5164328a-3833-4f5d-b54c-cdbe6ce7a04a@github.com>
Message-ID: <RbuUrUm4sBgoQTy4BRzXWcta_u-AzrwOV2YLaARoxeQ=.78dece5f-b345-420a-b655-5c3833cc4adb@github.com>

On Fri, 20 May 2022 21:08:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add documents
>
> src/java.base/share/classes/java/io/InputStream.java line 72:
> 
>> 70:      *
>> 71:      * @param size minimum length that the skip byte array must have.
>> 72:      *             notice that this param input MUST be equal or less than {@link #MAX_SKIP_BUFFER_SIZE MAX_SKIP_BUFFER_SIZE}.
> 
> The "MUST be equal" reads like something will go wrong if that condition isn't satisfied.
> This method does not care about the size, except in potentially resizing if the requested size is larger.
> 
> The "notice..." statement is making a statement about code in the caller, and so doesn't belong here.

The "notice..." statement removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue May 24 20:34:32 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 24 May 2022 20:34:32 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v14]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <-wROvf0d6b5PHrDwqqJf8ATtg8lxy-iUlTIt8zap-ME=.5bab498d-7beb-44d2-a60c-0d1dbbef14a0@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  refine javadoc, remove The "notice..." statement

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/580a542c..d082eae4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue May 24 20:40:51 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 24 May 2022 20:40:51 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v15]
In-Reply-To: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
Message-ID: <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>

> @jmehrens what about this then?
> I think it safe now(actually this mechanism is learned from Reader)

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  invert if; refine javadoc.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5872/files
  - new: https://git.openjdk.java.net/jdk/pull/5872/files/d082eae4..cdc4e579

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5872&range=13-14

  Stats: 8 lines in 1 file changed: 5 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5872.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue May 24 20:40:56 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 24 May 2022 20:40:56 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v12]
In-Reply-To: <QTDlYzqFPN4YaLgUFr7zY6yHyxBjCl0xHAqtJxduMf0=.5164328a-3833-4f5d-b54c-cdbe6ce7a04a@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <klI6NyXEyt_6yk0qlFaL0rsgczPFy5VNqsq5t0SlAmM=.947091f7-c3f0-49c6-b241-f2c1f2b9ff98@github.com>
 <QTDlYzqFPN4YaLgUFr7zY6yHyxBjCl0xHAqtJxduMf0=.5164328a-3833-4f5d-b54c-cdbe6ce7a04a@github.com>
Message-ID: <Zx_phnpaksTffyLAWvE_pDJI5DQr-I2cxeh6CsntZy0=.319b13c7-82ce-4270-9c06-342575ddb66e@github.com>

On Fri, 20 May 2022 21:15:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add documents
>
> src/java.base/share/classes/java/io/InputStream.java line 78:
> 
>> 76:         SoftReference<byte[]> ref = this.skipBufferReference;
>> 77:         byte[] buffer;
>> 78:         if (ref == null || (buffer = ref.get()) == null || buffer.length < size) {
> 
> A comment here or in the method javadoc to the effect that a new buffer is allocated unless the existing buffer is large enough might head off doubt that buffer is always non-null at the return.  As would inverting the if:
> 
>    if (ref != null && (buffer = ref.get()) != null && buffer.length >= size) {
>       return buffer;
>    }
>    // allocate new or larger buffer
>    buffer = new byte[size];
>    this.skipBufferReference = new SoftReference<>(buffer);
>    return buffer;

@RogerRiggs done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Tue May 24 20:54:57 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 24 May 2022 20:54:57 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v9]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <y9lfFuv7-bQ0LUY8VPlnDl6n-apZrwZxff5WGD2Xnrw=.4192d001-c4a6-44e9-997f-6a86749f8906@github.com>

> as title.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  revert much too changes for newHashSet

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/363fcc50..07e9b8b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=07-08

  Stats: 59 lines in 27 files changed: 9 ins; 0 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Tue May 24 20:54:58 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 24 May 2022 20:54:58 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v4]
In-Reply-To: <xMAQ0rG1GEFkU-ct6ub6Ezln8hoHnn2jHkmGWZ3J3bQ=.16aecdda-aa21-48a0-9f91-044a604651dd@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <dG50e4tph85P83R-ErBDznD1MCRHJ981upFennWzxTc=.afb7c439-9284-4396-94b1-8a9c6aac5d2e@github.com>
 <4I-FrEU8zBFD0-4pDPYZ948aQvIXHicUyTpbiUqKTj8=.377d95a6-af67-44be-8443-c4af58f8b95e@github.com>
 <9PqOY0Ho6mgINFO8ya5NeaZZB3RaATgWx7LJ-ESRSds=.37fdca9a-7af5-4ba5-8c85-baf9d33013ac@github.com>
 <xMAQ0rG1GEFkU-ct6ub6Ezln8hoHnn2jHkmGWZ3J3bQ=.16aecdda-aa21-48a0-9f91-044a604651dd@github.com>
Message-ID: <YNg3Vs1snlTuViO8e20Zbz4XVF76Zq9tT-jbKVHewes=.20c18ed4-455f-4d19-8466-d0ab9b56ed09@github.com>

On Wed, 18 May 2022 23:20:45 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> Need to add apiNote documentation section to capacity-based constructors like for maps.
>> 
>> @liach done.
>
> @XenoAmess oops, sorry for the delay. I think it would be good to get these into 19 as companions to `HashMap.newHashMap` et. al.
> 
> As before, I'd suggest reducing the number of changes to use sites in order to make review easier. I would suggest keeping the changes under src in java.base, java.net.http, java.rmi, and jdk.zipfs, and omitting all the other changes. Also keep the changes under test/jdk.
> 
> There needs to be a test for these new methods. I haven't thought much how to do that. My first attempt would be to modify our favorite WhiteBoxResizeTest and add a bit of machinery that asserts the table length of the HashMap contained within the created HashSet/LinkedHashSet. I haven't looked at it though, so it might not work out, in which case you should pursue an alternative approach.
> 
> I'll look at the specs and suggest updates as necessary and then handle filing of a CSR.

@stuart-marks

> suggest keeping the changes under src in java.base, java.net.http, java.rmi, and jdk.zipfs, and omitting all the other changes. Also keep the changes under test/jdk.

Done.

> modify our favorite WhiteBoxResizeTest and add a bit of machinery that asserts the table length of the HashMap contained within the created HashSet/LinkedHashSet.

I'm trying.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From sgehwolf at openjdk.java.net  Tue May 24 19:39:01 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 19:39:01 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v2]
In-Reply-To: <Ep6v5vDnXI4JIaR1xNn-Fmdj_l_-4WFkBLPqlArY9eI=.e9babec6-3e1a-4152-88b6-4a8fdbe83fa9@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
 <Ep6v5vDnXI4JIaR1xNn-Fmdj_l_-4WFkBLPqlArY9eI=.e9babec6-3e1a-4152-88b6-4a8fdbe83fa9@github.com>
Message-ID: <IcangTrRCuXa6VismUsCp6apXbvj64hriam6fZT5WlA=.befddda8-5cb8-4390-b42e-d13ce376b572@github.com>

On Tue, 24 May 2022 16:15:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode.
>> 
>> The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1).
>> 
>> However, the "hybrid checks" only considers the following controllers that Java cares about:
>> 
>> - cpu
>> - cpuacct
>> - cpuset
>> - blkio
>> - memory
>> - pids
>> 
>> If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert.
>> 
>> 
>> $ cat /proc/self/cgroup
>> 1:freezer:/
>> 0::/user.slice/user-1001.slice/session-85.scope
>> 
>> 
>> The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @jerboaa comments

Looks good. Thanks for the thorough analysis.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8858

From sgehwolf at openjdk.java.net  Tue May 24 19:39:04 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 24 May 2022 19:39:04 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v2]
In-Reply-To: <ddUidECANrWtWa9L99eKLekZaltBGZh07WPdZwadEpI=.adb52b74-6624-4b1f-bf7b-a62aef5b9aeb@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
 <EisSyVHbjSUIyBsszUjM97_OwD8Jt2cBIzSpXZpAEu8=.c62a5c40-e727-4f27-96d5-c7e5087725f0@github.com>
 <ddUidECANrWtWa9L99eKLekZaltBGZh07WPdZwadEpI=.adb52b74-6624-4b1f-bf7b-a62aef5b9aeb@github.com>
Message-ID: <pa4qHV9MGgYhWwOnMydw25tUfRFh7ozC-sez1mfPHIE=.126361a3-4b05-47e9-ab1a-f8589d31df2d@github.com>

On Tue, 24 May 2022 16:09:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 155:
>> 
>>> 153:                 // There are some controllers (such as freezer) that Java doesn't
>>> 154:                 // care about. Just ignore them. These are not considered in the
>>> 155:                 // anyCgroupsV1Controller/anyCgroupsV1Controller checks.
>> 
>> It's not clear why this `default` is necessary. Could we just add the comment like so:
>> 
>> 
>> // Intentional fall-through. There are controllers (such as freezer) that
>> // Java doesn't care about. Just ignore them. Only listed controllers are
>> // considered in the anyCgroupsV1Controller/anyCgroupsV2Controller checks.
>
> This is not a fall-through because the previous line ends with a `break`.

My bad. How about `Intentional incomplete switch. There are ...`? Anyway, why is the empty `default` case needed other than for the comment?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From iklam at openjdk.java.net  Tue May 24 21:13:05 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 24 May 2022 21:13:05 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v2]
In-Reply-To: <pa4qHV9MGgYhWwOnMydw25tUfRFh7ozC-sez1mfPHIE=.126361a3-4b05-47e9-ab1a-f8589d31df2d@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
 <EisSyVHbjSUIyBsszUjM97_OwD8Jt2cBIzSpXZpAEu8=.c62a5c40-e727-4f27-96d5-c7e5087725f0@github.com>
 <ddUidECANrWtWa9L99eKLekZaltBGZh07WPdZwadEpI=.adb52b74-6624-4b1f-bf7b-a62aef5b9aeb@github.com>
 <pa4qHV9MGgYhWwOnMydw25tUfRFh7ozC-sez1mfPHIE=.126361a3-4b05-47e9-ab1a-f8589d31df2d@github.com>
Message-ID: <RV2RrYZIThRLap-I9rJS4hitj4OHW5q6iBmABrAaWoE=.76f9fa14-987c-4e94-a94a-671a7e40c391@github.com>

On Tue, 24 May 2022 19:34:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is not a fall-through because the previous line ends with a `break`.
>
> My bad. How about `Intentional incomplete switch. There are ...`? Anyway, why is the empty `default` case needed other than for the comment?

To me, the `default:` switch is a clear indication that "everything else comes here". So you won't be confused whether the comment is related to the last line just above the comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From dholmes at openjdk.java.net  Tue May 24 21:13:59 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 24 May 2022 21:13:59 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
Message-ID: <my3reg3qq32EneIrhlsjzPOpMobJwr-Oot8lD7dlikk=.ddc77307-b08a-48ff-9c12-193b22dc0ab3@github.com>

On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot)
>>  - [x] Linux x86_32 fastdebug `tier3` (clean now)
>>  - [x] GHA run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another release test

There is a mistake in this changeset.  The JDK ProblemList already contained:

`java/nio/channels/FileChannel/LargeMapTest.java                 8286980 windows-all`

and this change then added:

`java/nio/channels/FileChannel/LargeMapTest.java                 8286642 generic-i586`

which appears to have negated the first entry.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From duke at openjdk.java.net  Tue May 24 21:37:52 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Tue, 24 May 2022 21:37:52 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v10]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>

> as title.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  add test for newHashSet and newLinkedHashSet

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/07e9b8b0..56d029f4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=08-09

  Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From darcy at openjdk.java.net  Wed May 25 00:26:29 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 25 May 2022 00:26:29 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations
Message-ID: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>

Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.

-------------

Commit messages:
 - Add floor and ceil.
 - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math and StrictMath

Changes: https://git.openjdk.java.net/jdk/pull/8876/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8876&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273346
  Stats: 108 lines in 4 files changed: 103 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8876.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8876/head:pull/8876

PR: https://git.openjdk.java.net/jdk/pull/8876

From darcy at openjdk.java.net  Wed May 25 00:35:24 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 25 May 2022 00:35:24 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
Message-ID: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>

> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:

 - Target JDK 20 rather than 19.
 - Merge branch 'master' into JDK-8266670
 - Add mask values to constants' javadoc.
 - Implement review feedback from mlchung.
 - Fix type in @throws tag.
 - Merge branch 'master' into JDK-8266670
 - Respond to review feedback.
 - Merge branch 'master' into JDK-8266670
 - Make workding changes suggested in review feedback.
 - Merge branch 'master' into JDK-8266670
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/60434fb7...05cf2d8b

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7445/files
  - new: https://git.openjdk.java.net/jdk/pull/7445/files/ead5911f..05cf2d8b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=18-19

  Stats: 255671 lines in 3128 files changed: 171304 ins; 68829 del; 15538 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.java.net/jdk/pull/7445

From darcy at openjdk.java.net  Wed May 25 00:35:24 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 25 May 2022 00:35:24 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v19]
In-Reply-To: <KarZng8o7H5bPfvRdG5L__rxnzB0etngvUrGY_D37rY=.178edfdc-2332-4e41-a702-d43743be6a1c@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <KarZng8o7H5bPfvRdG5L__rxnzB0etngvUrGY_D37rY=.178edfdc-2332-4e41-a702-d43743be6a1c@github.com>
Message-ID: <sa_PKbD0nRaAVbLNAullm137W-wgAET1WCFvhjAP7Pc=.d8de67cb-3355-4e46-8acf-eee309edfa1b@github.com>

On Tue, 3 May 2022 21:35:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add mask values to constants' javadoc.

Will take up work on this issue again for JDK 20.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From kbarrett at openjdk.java.net  Wed May 25 01:54:55 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 25 May 2022 01:54:55 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8]
In-Reply-To: <P_IG4tyJ06FNFBIiStcveZPGkbB1OGIrri3Iz31LFBA=.4fc4c7f5-2afd-4ac2-924f-06a271893368@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <P_IG4tyJ06FNFBIiStcveZPGkbB1OGIrri3Iz31LFBA=.4fc4c7f5-2afd-4ac2-924f-06a271893368@github.com>
Message-ID: <pvt4OknHt5t1m7yltFAyzH7TJYYut3TpLjwQFRCkUI8=.c7be8631-0582-4519-adc8-7dfdda2e44e5@github.com>

On Sun, 22 May 2022 08:40:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into gcc12-warnings
>  - Use getter function to access "_data"
>  - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp
>  - revert changes for memnode.cpp and type.cpp
>  - Add assert to check the range of BasicType
>  - Merge remote-tracking branch 'upstream/master' into HEAD
>  - Revert change for java.c , parse_manifest.c , LinuxPackage.c
>  - Calculate char offset before realloc()
>  - Use return value from JLI_Snprintf
>  - Avoid pragma error in before GCC 12
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70

Changes requested by kbarrett (Reviewer).

src/hotspot/share/oops/array.hpp line 102:

> 100:   // standard operations
> 101:   int  length() const                 { return _length; }
> 102:   T* data() const                     { return reinterpret_cast<T*>(reinterpret_cast<uintptr_t>(this) + base_offset_in_bytes()); }

Adding the const-qualifier to the `data()` function and then implicitly
casting it away (by casting through intptr_t) is wrong.  Either don't
const-qualify (and leave it to some future use that needs such to address
appropriately), or have two functions.  Also, the line length is excessive.
So this:


T* data() {
  return reinterpret_cast<T*>(
    reinterpret_cast<char*>(this) + base_offset_in_bytes());
}

and optionally add this:

const T* data() const {
  return reinterpret_cast<const T*>(
    reinterpret_cast<const char*>(this) + base_offset_in_bytes());
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From kbarrett at openjdk.java.net  Wed May 25 01:54:56 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 25 May 2022 01:54:56 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5]
In-Reply-To: <GYt9l65QBdx5_vIHgqckWcxDM8SZ1nCvxAOtk_jP_lI=.468be262-aa88-412f-9524-37241140df57@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <CO0gP8aVuyIwYVZqB0QDQbmyfIXrYKbb2fPP9TxnVaE=.879d8e41-5c1a-49d1-ba26-630478f35203@github.com>
 <IVH1Zox8com5hiHj00RjafTLFnmOQimXcj_rMYu6238=.b2187c5e-dcc9-4028-bc37-6c70bf0b7d1a@github.com>
 <hIsWyYSlUhRP7C95ZRVgCsbEM-16ZKIPg0Wf4u9OG5g=.81981efb-c599-4474-bbb9-d71786b6ab55@github.com>
 <iEuoewx3IZ0ZJpqpQQzrvvT3bHD_T58RrD6bI_DCUaY=.5ed80b90-f122-4ad3-8747-5a03dc3e8b31@github.com>
 <FftdUZXstTbgJoJ3uSN6IX9ectw1cZ_XOSSwk6v4PR0=.96511671-96b3-4bce-a1e6-cf0120a20b48@github.com>
 <GYt9l65QBdx5_vIHgqckWcxDM8SZ1nCvxAOtk_jP_lI=.468be262-aa88-412f-9524-37241140df57@github.com>
Message-ID: <2Fd9HKYBsrWvMvJoKwAL2tN010yXbzMGA15Vz1e9aRU=.80246fcf-ba7e-4ec7-aea3-ec2aa011e863@github.com>

On Sun, 22 May 2022 16:45:11 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> It might be GCC bug...
>> 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
>> 
>> This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`).
>
> I don't see the similarity.  That gcc bug is about literals used as addresses,
> which get treated (suggested inappropriately) as NULL+offset, with NULL+offset
> being a cause of warnings.  I don't see that happening in our case.  That is,
> in our `addr + low_offset`, `addr` doesn't seem to be either a literal or NULL
> that I can see.
> 
> It's hard for me to investigate this any further just by perusing the code, so
> I'm in the process of getting set up to build with gcc12.x.  That will let me
> do some experiments. It may take me a few days to get to that point though.

I spent some time looking into this one. I agree there is a false positive
here, and there doesn't seem to be a better solution than suppressing the
warning. I would prefer the change below, rather than what's proposed. Also
eliminate the changes to utilities/compilerWarnings files. This is a very
gcc-specific issue; there's no reason to generalize the solution.  The reason
for relocating the suppression is to be able to describe the issue in more
detail in a context where that description makes sense.

template <typename T>
inline void JfrTraceIdBits::store(jbyte bits, const T* ptr) {
  assert(ptr != NULL, "invariant");
  // gcc12 warns "writing 1 byte into a region of size 0" when T == Klass.
  // The warning seems to be a false positive.  And there is no warning for
  // other types that use the same mechanisms.  The warning also sometimes
  // goes away with minor code perturbations, such as replacing function calls
  // with equivalent code directly inlined.
  PRAGMA_DIAG_PUSH
  PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow")
  set(bits, traceid_tag_byte(ptr));
  PRAGMA_DIAG_POP
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From duke at openjdk.java.net  Wed May 25 01:49:52 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 25 May 2022 01:49:52 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v2]
In-Reply-To: <T1cgxeczSkx9ejS9ZcIDtGXPuCATMESMn4WuUOfbkYc=.bfbf3601-1d6a-4b0b-86a5-f2fc4918d5be@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <wzjh1NqTjoYU3FN8Vu2vlofpf_9gL-T9rCs0cQDPLUM=.d29d7d63-2aeb-4f06-b365-499c8b9bfceb@github.com>
 <T1cgxeczSkx9ejS9ZcIDtGXPuCATMESMn4WuUOfbkYc=.bfbf3601-1d6a-4b0b-86a5-f2fc4918d5be@github.com>
Message-ID: <m832ibXDtOixKgVUxy8Mwgq-D4t13Ba2v7iXMBgl4pQ=.92087508-97f8-4fc2-8a69-2a46304d046b@github.com>

On Tue, 24 May 2022 17:26:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Did you consider switch (class) {...} in PrimitiveTypeInfo.get?

I don't think we can switch on class instances yet. Even with preview enabled, best I can get is (for type incompatibility of `Class<?>` and `Class<Integer>`, etc.)

		return switch (cl) {
		    case Class<?> e && e == int.class -> 1;
		    case Class<?> e && e == long.class -> 2;
		    case Class<?> e && e == boolean.class -> 3;
		    case Class<?> e && e == short.class -> 4;
		    case Class<?> e && e == byte.class -> 5;
		    case Class<?> e && e == char.class -> 6;
		    case Class<?> e && e == float.class -> 7;
		    case Class<?> e && e == double.class -> 8;
		    default -> 0;
		};

to avoid type incompatibility; this is in turn implemented by a bootstrap method and a loop, which is of course obviously much slower.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From duke at openjdk.java.net  Wed May 25 03:06:49 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Wed, 25 May 2022 03:06:49 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v10]
In-Reply-To: <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
Message-ID: <-Lz_SOx7WHvfqv36TSbyZ9yt776HP8lomlb6qTICfyk=.ca9d268e-86eb-4d4e-aec9-aea81ba5ca04@github.com>

On Tue, 24 May 2022 21:37:52 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test for newHashSet and newLinkedHashSet

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 360:

> 358:                         throw new RuntimeException(e);
> 359:                     }
> 360:                 })

These?probably?need a?`mapField.setAccessible(true)`?call, or?a?`VarHandle` for?the?`HashSet.map`?field.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From jlahoda at openjdk.java.net  Wed May 25 04:20:35 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 25 May 2022 04:20:35 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v7]
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <vZkgWSviWgMBL3GDPgWtwtzoAIy_YDpd4ek5_eUiQps=.4786f5fe-6978-4d29-9f31-2c57c82a298a@github.com>

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into patterns-record-deconstruction3
 - Post merge fix.
 - Merge branch 'master' into patterns-record-deconstruction3
 - Fixing (non-)exhaustiveness for enum.
 - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
 - Merge branch 'master' into type-patterns-third
 - Using Type.isRaw instead of checking the AST structure.
 - Exhaustiveness should accept supertypes of the specified type.
 - Renaming the features from deconstruction pattern to record pattern.
 - Fixing guards after record patterns.
 - ... and 24 more: https://git.openjdk.java.net/jdk/compare/742644e2...f49d3f0a

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8516&range=06
  Stats: 2255 lines in 50 files changed: 2169 ins; 15 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516

PR: https://git.openjdk.java.net/jdk/pull/8516

From darcy at openjdk.java.net  Wed May 25 04:25:59 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 25 May 2022 04:25:59 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v2]
In-Reply-To: <wzjh1NqTjoYU3FN8Vu2vlofpf_9gL-T9rCs0cQDPLUM=.d29d7d63-2aeb-4f06-b365-499c8b9bfceb@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <wzjh1NqTjoYU3FN8Vu2vlofpf_9gL-T9rCs0cQDPLUM=.d29d7d63-2aeb-4f06-b365-499c8b9bfceb@github.com>
Message-ID: <PFDvCgt873EauwltWSbPAtkhmhlGPsG-OGtsQ-R1pFM=.ad139ac2-4eba-482d-8ec2-f520dd66f814@github.com>

On Fri, 20 May 2022 22:18:42 GMT, liach <duke at openjdk.java.net> wrote:

>> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert PrimitiveTypeInfo to an enum

> > Did you consider switch (class) {...} in PrimitiveTypeInfo.get?
> 
> I don't think we can switch on class instances yet. Even with preview enabled, best I can get is (for type incompatibility of `Class<?>` and `Class<Integer>`, etc.)
> 
> ```java
> 		return switch (cl) {
> 		    case Class<?> e && e == int.class -> 1;
> 		    case Class<?> e && e == long.class -> 2;
> 		    case Class<?> e && e == boolean.class -> 3;
> 		    case Class<?> e && e == short.class -> 4;
> 		    case Class<?> e && e == byte.class -> 5;
> 		    case Class<?> e && e == char.class -> 6;
> 		    case Class<?> e && e == float.class -> 7;
> 		    case Class<?> e && e == double.class -> 8;
> 		    default -> 0;
> 		};
> ```
> 
> to avoid type incompatibility; this is in turn implemented by a bootstrap method and a loop, which is of course obviously much slower.

Not necessarily recommending this coding idiom, but if you screened on Class.isPrimitive() being true (taking care to avoid void.class), you could switch on the string presentations on the class such as getName or getSimpleName.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From duke at openjdk.java.net  Wed May 25 04:53:50 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 25 May 2022 04:53:50 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v10]
In-Reply-To: <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
Message-ID: <eed5Bgj0PTL0VXr_xpLzuasG5I7EY_E6UtE7Blcn1O4=.bca7531c-c170-4de7-9ebf-be7440f5848c@github.com>

On Tue, 24 May 2022 21:37:52 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test for newHashSet and newLinkedHashSet

test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 354:

> 352:                 rsc("rsls", size, cap, () -> {
> 353:                     try {
> 354:                         Field mapField = HashSet.class.getDeclaredField("map");

For clarity, consider using var handle/method handle and keep the reflection code in the `WhiteBoxResizeTest` constructor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed May 25 05:12:40 2022
From: duke at openjdk.java.net (liach)
Date: Wed, 25 May 2022 05:12:40 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v2]
In-Reply-To: <wzjh1NqTjoYU3FN8Vu2vlofpf_9gL-T9rCs0cQDPLUM=.d29d7d63-2aeb-4f06-b365-499c8b9bfceb@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <wzjh1NqTjoYU3FN8Vu2vlofpf_9gL-T9rCs0cQDPLUM=.d29d7d63-2aeb-4f06-b365-499c8b9bfceb@github.com>
Message-ID: <QDJL6kr3UWg4Phthd2uxSsUwR3AV8lty-f-9Bt8eRGI=.cc0e054d-7593-4272-9e59-c7ab07873130@github.com>

On Fri, 20 May 2022 22:18:42 GMT, liach <duke at openjdk.java.net> wrote:

>> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert PrimitiveTypeInfo to an enum

I would prefer to look up in a `Map.ofEntries` than to switch on string class names, which is both faster and clearer. The even faster heuristic of using perfect hash table has already been proven slower than the list of if statements in JDK-8284880, referred to in the pull request description.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From shade at openjdk.java.net  Wed May 25 05:41:36 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 May 2022 05:41:36 GMT
Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom
 integration [v3]
In-Reply-To: <my3reg3qq32EneIrhlsjzPOpMobJwr-Oot8lD7dlikk=.ddc77307-b08a-48ff-9c12-193b22dc0ab3@github.com>
References: <JUo23d9Y9k4iN1A7Lp3b9RC9RqK79TcnSFsGzGrlgDs=.1f5b39d2-6c5c-4138-9d7b-09fa4575b9fd@github.com>
 <JZR_HPYsW-yt4BdPHxKyGHfRHHdhUe9M2C-KDbim0Os=.9d866a5c-e32c-4ede-a011-bf0c33b629eb@github.com>
 <my3reg3qq32EneIrhlsjzPOpMobJwr-Oot8lD7dlikk=.ddc77307-b08a-48ff-9c12-193b22dc0ab3@github.com>
Message-ID: <Vvc9G3QcGPEWnA-2D9twMPBJgewfG_x0ty2XUcGUO5s=.47093993-797e-4b1e-b85e-35638a6aa2c1@github.com>

On Tue, 24 May 2022 21:10:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Just FYI. There is a mistake in this changeset. The JDK ProblemList already contained:
> 
> `java/nio/channels/FileChannel/LargeMapTest.java 8286980 windows-all`
> 
> and this change then added:
> 
> `java/nio/channels/FileChannel/LargeMapTest.java 8286642 generic-i586`
> 
> which appears to have negated the first entry.

Whoops, sorry. It seems not to be a problem since [JDK-8287263](https://bugs.openjdk.java.net/browse/JDK-8287263) committed a few hours ago removed the `windows-all` entry and fixed the test. I checked other ProblemLists, and there are no other double entries.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8843

From smarks at openjdk.java.net  Wed May 25 05:45:56 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 25 May 2022 05:45:56 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v10]
In-Reply-To: <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
Message-ID: <ygVOfOf_7rweffzpsQpkhpkD4xmWWMDWzgO77th2jcg=.75ef70a8-fc7b-476d-b7dc-ecfbdea832bf@github.com>

On Tue, 24 May 2022 21:37:52 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add test for newHashSet and newLinkedHashSet

I looked at all the use sites and they look fine. Some look like they could use additional cleanup, but that's probably beyond the scope of this change. (Also, I haven't seen `StringTokenizer` in a long time....) It's amazing how many bugs there are -- the majority look like they allocated the HashSet with the wrong capacity! Again, this proves the worth of these new APIs.

src/java.base/share/classes/java/util/HashSet.java line 398:

> 396:     public static <E> HashSet<E> newHashSet(int numItems) {
> 397:         return new HashSet<>(HashMap.calculateHashMapCapacity(numItems));
> 398:     }

Please use "elements" instead of "items" throughout the specifications for the objects that are members of the HashSet. This includes the API notes above as well as the specs and API notes in LinkedHashSet.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From smarks at openjdk.java.net  Wed May 25 05:45:59 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 25 May 2022 05:45:59 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v10]
In-Reply-To: <-Lz_SOx7WHvfqv36TSbyZ9yt776HP8lomlb6qTICfyk=.ca9d268e-86eb-4d4e-aec9-aea81ba5ca04@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
 <-Lz_SOx7WHvfqv36TSbyZ9yt776HP8lomlb6qTICfyk=.ca9d268e-86eb-4d4e-aec9-aea81ba5ca04@github.com>
Message-ID: <stq4JTmCFMDrKktVkCrQw-q-9rpDuM4crfEBv9tJ4yQ=.60e57538-8f98-408a-bd67-45666bc9aee5@github.com>

On Wed, 25 May 2022 03:02:45 GMT, ExE Boss <duke at openjdk.java.net> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test for newHashSet and newLinkedHashSet
>
> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 360:
> 
>> 358:                         throw new RuntimeException(e);
>> 359:                     }
>> 360:                 })
> 
> These?probably?need a?`mapField.setAccessible(true)`?call, or?a?`VarHandle` for?the?`HashSet.map`?field.

Yes, this test fails with IllegalAccessException. Probably it's easiest to use a VarHandle to get private fields, similar to other usage already in this test.

This test case is a bit odd though in that it's supposed to test HashSet and LinkedHashSet but it mostly actually tests HashMap. It creates the Set instance and immediately extracts the HashMap, which is then passed to the actual test, which operates directly on the HashMap. It would be preferable to create a Set; add an element (so that it's properly allocated); and then make assertions over the Set (which involve extracting the HashMap, etc.) It seems like there should be factoring that allows this sort of arrangement to be retrofitted without adding too much complication.

Finally, please add "8284780" to the `@bug` line at the top of this test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From jbhateja at openjdk.java.net  Wed May 25 05:50:23 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 25 May 2022 05:50:23 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v9]
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <XOdud1tXGKpB0r0eVOyrQyPRF6I_cnnYHyaTep-sMsA=.f0e9e656-39c9-4505-b21f-bac023c32ccf@github.com>

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8284960: Review comments resolved.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8425/files
  - new: https://git.openjdk.java.net/jdk/pull/8425/files/17a0e38c..a2c9673d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=07-08

  Stats: 110 lines in 7 files changed: 42 ins; 31 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425

PR: https://git.openjdk.java.net/jdk/pull/8425

From jbhateja at openjdk.java.net  Wed May 25 06:29:23 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 25 May 2022 06:29:23 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v10]
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <VHAcCWLYeUyK0upiw42TqjQ_FvoSrzj2bLEFbvkZCF8=.165b6038-072b-4d77-a070-461604c782c7@github.com>

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - 8284960: Post merge cleanups.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Review comments resolved.
 - 8284960: Integrating incremental patches.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms.
 - 8284960: Adding --enable-preview in vectorAPI benchmarks.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - 8284960: Review comments resolution.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/742644e2...0f6e1584

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8425/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=09
  Stats: 38021 lines in 228 files changed: 16652 ins; 16924 del; 4445 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425

PR: https://git.openjdk.java.net/jdk/pull/8425

From jbhateja at openjdk.java.net  Wed May 25 06:29:24 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 25 May 2022 06:29:24 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v8]
In-Reply-To: <MIC5Sq_7Vvy7XAkLQ-HFQ0ydRv8XPHuBQhR53eSLQN0=.3b396db1-43fd-4348-b89c-ff8377281c91@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
 <MIC5Sq_7Vvy7XAkLQ-HFQ0ydRv8XPHuBQhR53eSLQN0=.3b396db1-43fd-4348-b89c-ff8377281c91@github.com>
Message-ID: <4u_PL8-QxIYVBgJ23LTdoPWZrTKh70K-beMYXOXZgQQ=.a650a280-dc75-46cd-8449-00c38ddd91ea@github.com>

On Mon, 23 May 2022 22:17:40 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8284960: Integrating incremental patches.
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 8173:
> 
>> 8171: 
>> 8172: void Assembler::vinsertf32x4(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>> 8173:   assert(VM_Version::supports_evex(), "");
> 
> Hmm, did we never trigger this wrong assert because the use was guarded by correct check?

Yes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From jbhateja at openjdk.java.net  Wed May 25 06:32:19 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 25 May 2022 06:32:19 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v9]
In-Reply-To: <XOdud1tXGKpB0r0eVOyrQyPRF6I_cnnYHyaTep-sMsA=.f0e9e656-39c9-4505-b21f-bac023c32ccf@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <XOdud1tXGKpB0r0eVOyrQyPRF6I_cnnYHyaTep-sMsA=.f0e9e656-39c9-4505-b21f-bac023c32ccf@github.com>
Message-ID: <QGHTZd-YKn_P2rF_qyIoxuysgQzOuw53e21tx6OolKk=.6465c8fc-3464-4ed4-ac32-f37f18004736@github.com>

On Wed, 25 May 2022 05:50:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8284960: Review comments resolved.

Hi @vnkozlov , Your comments have been addressed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From aturbanov at openjdk.java.net  Wed May 25 07:28:00 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 25 May 2022 07:28:00 GMT
Subject: Integrated: 8287181: Avoid redundant HashMap.containsKey calls in
 InternalLocaleBuilder.setExtension
In-Reply-To: <Xzpw4lqoOLnSpSrkfIeCbh-Gq9Ru2BQpiYLuA5Wkn1o=.1f208f43-fe60-4e6c-8dcf-a23a625be047@github.com>
References: <Xzpw4lqoOLnSpSrkfIeCbh-Gq9Ru2BQpiYLuA5Wkn1o=.1f208f43-fe60-4e6c-8dcf-a23a625be047@github.com>
Message-ID: <agLfym7hHiglU8Un_ZXd95evJZjGM2UP583GJXZP148=.49b350ab-f78b-4468-8e3e-5c9187c22d56@github.com>

On Sat, 30 Apr 2022 17:10:55 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to separately perform `HashMap.containsKey` before `HashMap.remove` call. If key is present - it will be removed anyway. If it's not present, nothing will be deleted.

This pull request has now been integrated.

Changeset: 65850431
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/65850431edd321c4cf49875f756ae28449c9f710
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8287181: Avoid redundant HashMap.containsKey calls in InternalLocaleBuilder.setExtension

Reviewed-by: naoto, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8488

From aturbanov at openjdk.java.net  Wed May 25 08:05:16 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 25 May 2022 08:05:16 GMT
Subject: RFR: 8287285: Avoid redundant HashMap.containsKey call in
 java.util.zip.ZipFile.Source.get
Message-ID: <ZupMHluCLPM_cAsoG4beDZ_z3-aRel-v7M_2w3OVPi4=.29a36738-15d5-42ca-bb20-a38b2f4b22d1@github.com>

The method `java.util.zip.ZipFile.Source#get` could be improved by usage of `Map.putIfAbsent` instead of separate `containsKey`/`get`/`put` calls. We known that HashMap `java.util.zip.ZipFile.Source#files` can contain only non-null values. And to check if putIfAbsent was successful or not we can just compare result with `null`.
It makes code a bit cleaner and faster.

-------------

Commit messages:
 - [PATCH] Avoid redundant Map.containsKey in ZipFile

Changes: https://git.openjdk.java.net/jdk/pull/8481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8481&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287285
  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8481.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8481/head:pull/8481

PR: https://git.openjdk.java.net/jdk/pull/8481

From sgehwolf at openjdk.java.net  Wed May 25 08:43:50 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 25 May 2022 08:43:50 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v2]
In-Reply-To: <RV2RrYZIThRLap-I9rJS4hitj4OHW5q6iBmABrAaWoE=.76f9fa14-987c-4e94-a94a-671a7e40c391@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
 <EisSyVHbjSUIyBsszUjM97_OwD8Jt2cBIzSpXZpAEu8=.c62a5c40-e727-4f27-96d5-c7e5087725f0@github.com>
 <ddUidECANrWtWa9L99eKLekZaltBGZh07WPdZwadEpI=.adb52b74-6624-4b1f-bf7b-a62aef5b9aeb@github.com>
 <pa4qHV9MGgYhWwOnMydw25tUfRFh7ozC-sez1mfPHIE=.126361a3-4b05-47e9-ab1a-f8589d31df2d@github.com>
 <RV2RrYZIThRLap-I9rJS4hitj4OHW5q6iBmABrAaWoE=.76f9fa14-987c-4e94-a94a-671a7e40c391@github.com>
Message-ID: <f2VI8ODNEnRwjN1oZKd0aGc3UwuwT3yMijcxYLSyetk=.2763038e-74a3-4ab0-8878-9dd42e01e58d@github.com>

On Tue, 24 May 2022 19:49:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> My bad. How about `Intentional incomplete switch. There are ...`? Anyway, why is the empty `default` case needed other than for the comment?
>
> To me, the `default:` switch is a clear indication that "everything else comes here". So you won't be confused whether the comment is related to the last line just above the comment.

It confused me, fwiw. Anyway up to you. It's not super important.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From ysuenaga at openjdk.java.net  Wed May 25 09:16:43 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 25 May 2022 09:16:43 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9]
In-Reply-To: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
Message-ID: <zll-VXYgVeeBoeccn4lFcOrvlpyjO5N61vqnkt5EKeg=.853ed5c9-5d0e-4acc-9e75-079f20b0e542@github.com>

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
> 
> * -Wstringop-overflow
>     * src/hotspot/share/oops/array.hpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
> 
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:

 - Change Array::data() implementation
 - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8646/files
  - new: https://git.openjdk.java.net/jdk/pull/8646/files/042c1c70..17cda224

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=07-08

  Stats: 39 lines in 4 files changed: 18 ins; 18 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Wed May 25 09:16:45 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 25 May 2022 09:16:45 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8]
In-Reply-To: <pvt4OknHt5t1m7yltFAyzH7TJYYut3TpLjwQFRCkUI8=.c7be8631-0582-4519-adc8-7dfdda2e44e5@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <P_IG4tyJ06FNFBIiStcveZPGkbB1OGIrri3Iz31LFBA=.4fc4c7f5-2afd-4ac2-924f-06a271893368@github.com>
 <pvt4OknHt5t1m7yltFAyzH7TJYYut3TpLjwQFRCkUI8=.c7be8631-0582-4519-adc8-7dfdda2e44e5@github.com>
Message-ID: <9kogffvvtXsQPgsozHqM-4XQlGBFZv8JVURdlpX0W4s=.68aa1f9e-4abd-405a-accf-e931090623ea@github.com>

On Wed, 25 May 2022 01:50:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into gcc12-warnings
>>  - Use getter function to access "_data"
>>  - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp
>>  - revert changes for memnode.cpp and type.cpp
>>  - Add assert to check the range of BasicType
>>  - Merge remote-tracking branch 'upstream/master' into HEAD
>>  - Revert change for java.c , parse_manifest.c , LinuxPackage.c
>>  - Calculate char offset before realloc()
>>  - Use return value from JLI_Snprintf
>>  - Avoid pragma error in before GCC 12
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70
>
> src/hotspot/share/oops/array.hpp line 102:
> 
>> 100:   // standard operations
>> 101:   int  length() const                 { return _length; }
>> 102:   T* data() const                     { return reinterpret_cast<T*>(reinterpret_cast<uintptr_t>(this) + base_offset_in_bytes()); }
> 
> Adding the const-qualifier to the `data()` function and then implicitly
> casting it away (by casting through intptr_t) is wrong.  Either don't
> const-qualify (and leave it to some future use that needs such to address
> appropriately), or have two functions.  Also, the line length is excessive.
> So this:
> 
> 
> T* data() {
>   return reinterpret_cast<T*>(
>     reinterpret_cast<char*>(this) + base_offset_in_bytes());
> }
> 
> and optionally add this:
> 
> const T* data() const {
>   return reinterpret_cast<const T*>(
>     reinterpret_cast<const char*>(this) + base_offset_in_bytes());
> }

Thanks a lot @kimbarrett !

I updated around stringop-overflow warning in jfrTraceIdBits.inline.hpp , and added two `data()` in `Array` class. They works fine on my GCC 12 on Fedora 36. Could you review again?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From jpai at openjdk.java.net  Wed May 25 09:20:57 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 25 May 2022 09:20:57 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v3]
In-Reply-To: <W1pm_d2_eCjJYnMxHG91-nMZf-N9Rq2_cr5Yu-iqSG0=.d1db4723-3108-4c0c-8c5c-c07b309a54ec@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
 <Uh30nZyDeqt2ARI5Y-FXoBKabCJxYebhgaimCdixxOo=.87c7c3c5-6310-45f2-b9b8-b390052c1f9e@github.com>
 <1XOcr-j-27aYsiJnYQ5UYUaBTO_stl-hZlnsKulgW3c=.1d384bf9-e88b-407d-9423-6dc6234025cd@github.com>
 <W1pm_d2_eCjJYnMxHG91-nMZf-N9Rq2_cr5Yu-iqSG0=.d1db4723-3108-4c0c-8c5c-c07b309a54ec@github.com>
Message-ID: <aejI8G1TQtKRYlqpbRQmtTdEWofXnwVNCDGAwiMFMuk=.bc816b3e-0909-416d-91e6-ebeaa169708e@github.com>

On Tue, 24 May 2022 13:07:08 GMT, liach <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 605:
>> 
>>> 603:         mv.visitLdcInsn(Type.getObjectType(dotToSlash(className)));
>>> 604:         mv.visitMethodInsn(INVOKEVIRTUAL, JL_CLASS,
>>> 605:                 "getClassLoader", "()" + LJL_CLASSLOADER, false);
>> 
>> Hello @liach, should this instead be using the (application supplied) `loader` returned by the call to `ProxyGenerator.getClassLoader()` or maybe the `loader` member in the `ProxyGenerator` itself?
>
> This is equivalent to `jdk.proxy5.$Proxy5.class.getClassLoader()` in Java source code, so this is exactly the application-supplied loader, which also uses the same loader as the previous behavior of `forName` calls.
> 
> If you want to pass the loader from `ProxyGenerator` to the proxy, it requires complex tricks. Hidden classes won't work due to serialization incompatibility; accessor methods would be defined in `jdk.internal` and exported specifically to the proxy modules, but writing a class so each proxy gets its loader while what I wrote can already do is overkill.

Thank you @liach for that detail.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8800

From jpai at openjdk.java.net  Wed May 25 09:24:57 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 25 May 2022 09:24:57 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v3]
In-Reply-To: <W1pm_d2_eCjJYnMxHG91-nMZf-N9Rq2_cr5Yu-iqSG0=.d1db4723-3108-4c0c-8c5c-c07b309a54ec@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
 <Uh30nZyDeqt2ARI5Y-FXoBKabCJxYebhgaimCdixxOo=.87c7c3c5-6310-45f2-b9b8-b390052c1f9e@github.com>
 <1XOcr-j-27aYsiJnYQ5UYUaBTO_stl-hZlnsKulgW3c=.1d384bf9-e88b-407d-9423-6dc6234025cd@github.com>
 <W1pm_d2_eCjJYnMxHG91-nMZf-N9Rq2_cr5Yu-iqSG0=.d1db4723-3108-4c0c-8c5c-c07b309a54ec@github.com>
Message-ID: <fSfzZ58agLjeF_eBtlWfqeoQckSF5gIi-a35aPFEr-c=.a40ec4c5-bb0a-4c53-a2d9-af7da73f326b@github.com>

On Tue, 24 May 2022 13:08:53 GMT, liach <duke at openjdk.java.net> wrote:

> so on a mismatch, it would print parameter type initialized after instantiation expected: true actual: false

That looks fine then. I hadn't looked closely at what testng prints and I had thought that on an assertion failure it would print only `AssertionError: parameter type initialized after instantiation` which wouldn't be accurate. The one you note above is more clear.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8800

From duke at openjdk.java.net  Wed May 25 09:31:09 2022
From: duke at openjdk.java.net (iaroslavski)
Date: Wed, 25 May 2022 09:31:09 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <AdrqO690TmYSLibGVRn4CBgHvdmQunOJgVmjFJGjRRw=.e5d09541-fdcc-437f-bffd-490c55c9d291@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

Hi Piotr,

I agree that catching out-of-memory-error is very rarely in prod.
I can say that LSD Radix sort works 3-5 times faster than Quicksort
(array of int 2M elements), merging sort works 10-30 (!) times faster
than Quicksort (structured array of int 2M elements), therefore it
is worth to use algorithms with additional buffers.

If we allocate buffer like 'new int[size]' and there is no free memory,
sorting fails with OOME. If we catch memory error, we switch to
in-place algorithms and sorting will be completed successfully.
I checked such use case, it works fine.

It doesn't matter if we run several threads or not. Some threads
may use additional buffers, some threads - not, but finally
all threads will be completed without errors.

The known problem with OOME is handling inside catch block.
If we try to create new object, try to log message with details,
we can face with new OOME. In DualPivotQuicksort we return null only,
no any actions, no new objects etc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From mcimadamore at openjdk.java.net  Wed May 25 09:37:05 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 25 May 2022 09:37:05 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v3]
In-Reply-To: <WB-jlVcwVv0n9Ut4s8w6a20X-P-qJFIYmxd1DOfau9Y=.665df86a-d1f7-4936-b08c-a2591af44017@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <WB-jlVcwVv0n9Ut4s8w6a20X-P-qJFIYmxd1DOfau9Y=.665df86a-d1f7-4936-b08c-a2591af44017@github.com>
Message-ID: <IdjUYSEYAZGrIG6xoXTWNxcHkSYqhLChY4V_YT2Z5s8=.d8a5f24b-b8db-4074-bf97-2d88ee06cc63@github.com>

On Tue, 24 May 2022 15:15:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>> 
>> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add statement to close about thread termination

Looks good!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8787

From duke at openjdk.java.net  Wed May 25 09:37:11 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 25 May 2022 09:37:11 GMT
Subject: RFR: 8273346: Expand library mappings to IEEE 754 operations
In-Reply-To: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
References: <Ej8lxIXgKgi90zab0dMOlOztBEuoGTx2LBWG24m-mxM=.ce2f357e-491c-4670-a7bc-962799dde80c@github.com>
Message-ID: <fjkuVCnfgQI6M0tObWQ2TEuaZ2rhhdZMBL9-3WvdTRE=.23dfd09e-6760-418b-896c-376d507bd185@github.com>

On Wed, 25 May 2022 00:19:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath.

src/java.base/share/classes/java/lang/Math.java line 771:

> 769:      * This method corresponds to the convertToIntegerTiesToEven
> 770:      * operation defined in IEEE 754.
> 771:      *

IEEE `convertToIntegerTiesToEven` rounds ties to the even integer.
The method's spec, however, requires ties to round toward positive infinity.
Unfortunately, IEEE 754 doesn't offer a `convertToIntegerTiesToPositive`

src/java.base/share/classes/java/lang/Math.java line 824:

> 822:      * This method corresponds to the convertToIntegerTiesToEven
> 823:      * operation defined in IEEE 754.
> 824:      *

see comment for `round(float)`

src/java.base/share/classes/java/math/RoundingMode.java line 49:

> 47:  * exponent range of {@code BigDecimal}, the mathematical result will
> 48:  * be exactly representable in the result precision or fall between
> 49:  * two representable values. In the case of falling between two

Perhaps better would be
`two adjacent representable values.`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8876

From duke at openjdk.java.net  Wed May 25 09:40:42 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 25 May 2022 09:40:42 GMT
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts [v6]
In-Reply-To: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
Message-ID: <VKdxc6IyKkKUbnjZsUCP8qEfVX87r3x74R8woOq-s8Y=.2d8f4482-36f8-4f19-82dc-a54d4fecdd3d@github.com>

> Add a family of "safe" cast methods.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8279986: methods Math::asXExact for safely checked primitive casts

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8548/files
  - new: https://git.openjdk.java.net/jdk/pull/8548/files/5fb1fed4..4cf9a8cf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8548&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8548&range=04-05

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548

PR: https://git.openjdk.java.net/jdk/pull/8548

From redestad at openjdk.java.net  Wed May 25 09:46:32 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 25 May 2022 09:46:32 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of transforms
 efficiently
Message-ID: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>

The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.

Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:

Baseline:

Benchmark                                                      Mode  Cnt     Score     Error   Units
SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op


Patched:

Benchmark                                                      Mode  Cnt     Score     Error   Units
SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op

-------------

Commit messages:
 - Revert unrelated and unverified hashCode change
 - Improve TransformKey to pack more kinds of transforms efficiently

Changes: https://git.openjdk.java.net/jdk/pull/8881/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8881&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287292
  Stats: 44 lines in 1 file changed: 21 ins; 10 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8881.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8881/head:pull/8881

PR: https://git.openjdk.java.net/jdk/pull/8881

From mcimadamore at openjdk.java.net  Wed May 25 09:55:03 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 25 May 2022 09:55:03 GMT
Subject: Integrated: 8287206: Use WrongThreadException for confinement errors
In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
Message-ID: <jgbLZMG5ZtArkLmVfJzQ0YTTKbxmrIpH7AopTIfUFy8=.d1f2d277-879e-4431-ac0d-0030eacd28bd@github.com>

On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors.

This pull request has now been integrated.

Changeset: e1f140d2
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e1f140d270cc666d26b888a0a25ca7b02e1239af
Stats:     254 lines in 12 files changed: 150 ins; 1 del; 103 mod

8287206: Use WrongThreadException for confinement errors

Reviewed-by: alanb, darcy, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8865

From lbourges at openjdk.java.net  Wed May 25 10:04:02 2022
From: lbourges at openjdk.java.net (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 25 May 2022 10:04:02 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <NR6HcFWht4Ze2BfyEaxHMLGCq69Q70fvgk9Ro4X4XSI=.025b204b-d64f-463d-b9ba-7300e7833c8e@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

Well explained, vladimir.

I propose to adopt max_heap / 128 min to stay less than 1% footprint.

Then factors are 7 for ints, 8 for long, min.

For 1gb heap, it gives 8mb, so 2m ints or 1m long.

Laurent

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From uschindler at openjdk.java.net  Wed May 25 10:09:01 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 25 May 2022 10:09:01 GMT
Subject: RFR: 8287206: Use WrongThreadException for confinement errors
In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
Message-ID: <PCtBms0P2_Dn5isJmp5KOT23Oycyg8ekUygvZAx88O8=.965b9b43-a0be-40ad-a579-099bb54a1fb4@github.com>

On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors.

I have seen this PR now: Would it be also a good idea to replace the `IllegalStateException` for already closed `MemorySession` by some special exception? In Lucene we catch `IllegalStateException` in our IO layer and check if message contains "closed", example:
- https://github.com/apache/lucene/blob/d182134bf88a44bf76ebd1c1d40b225ecdca1f4b/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java#L137 (catch)
- https://github.com/apache/lucene/blob/d182134bf88a44bf76ebd1c1d40b225ecdca1f4b/lucene/core/src/java/org/apache/lucene/store/MemorySegmentIndexInput.java#L93-L103 (that's the hack)

The check using `ex.getMessage().contains("closed")` feels bad, especially if it may be translated to a locale.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8865

From uschindler at openjdk.java.net  Wed May 25 10:11:24 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 25 May 2022 10:11:24 GMT
Subject: RFR: 8287206: Use WrongThreadException for confinement errors
In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
Message-ID: <aeOtCxFKcVZicBfREW3_cb9I9V8xc5SpBCIMxOYIUZI=.8ab55a3f-b417-4f99-be64-17b66b2a760a@github.com>

On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors.

Thinking more about it: `IllegalStateException` is fine for a closed `MemorySession`. If used by wrong thread the exception was indeed confusing. Now that the abiguity is gone, I can change our (Lucene) code and just transform every ISE to an already closed in our code. I just wanted to bring up that issue here.

PR is here: https://github.com/apache/lucene/pull/912

-------------

PR: https://git.openjdk.java.net/jdk/pull/8865

From mcimadamore at openjdk.java.net  Wed May 25 10:18:55 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 25 May 2022 10:18:55 GMT
Subject: RFR: 8287206: Use WrongThreadException for confinement errors
In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
Message-ID: <3fiLF2goGBXqo6BqFntFkt-Nbtdq7cLpaMsjEftJ95I=.6e708ab4-9524-455b-9585-84e43ccbcf09@github.com>

On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors.

> Thinking more about it: `IllegalStateException` is fine for a closed `MemorySession`. If used by wrong thread the exception was indeed confusing. Now that the abiguity is gone, I can change our (Lucene) code and just transform every ISE to an already closed in our code. I just wanted to bring up that issue here.
> 
> PR is here: [apache/lucene#912](https://github.com/apache/lucene/pull/912)

I've been thinking something similar. I'd suggest to keep the API as is, and maybe revise it at a later point if lack of a specific exception for the "already closed" case proves to be too cumbersome to workaround.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8865

From mcimadamore at openjdk.java.net  Wed May 25 10:22:49 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 25 May 2022 10:22:49 GMT
Subject: RFR: 8287206: Use WrongThreadException for confinement errors
In-Reply-To: <3fiLF2goGBXqo6BqFntFkt-Nbtdq7cLpaMsjEftJ95I=.6e708ab4-9524-455b-9585-84e43ccbcf09@github.com>
References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
 <3fiLF2goGBXqo6BqFntFkt-Nbtdq7cLpaMsjEftJ95I=.6e708ab4-9524-455b-9585-84e43ccbcf09@github.com>
Message-ID: <n6V17BYXzQkpgNVkkf5k0WKJ2EFbljLbiw3_e-o9gkc=.d243f4fa-4af2-4dbb-b39c-cd941b7deb4c@github.com>

On Wed, 25 May 2022 10:16:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Thinking more about it: `IllegalStateException` is fine for a closed `MemorySession`. If used by wrong thread the exception was indeed confusing. Now that the abiguity is gone, I can change our (Lucene) code and just transform every ISE to an already closed in our code. I just wanted to bring up that issue here.
> > PR is here: [apache/lucene#912](https://github.com/apache/lucene/pull/912)
> 
> I've been thinking something similar. I'd suggest to keep the API as is, and maybe revise it at a later point if lack of a specific exception for the "already closed" case proves to be too cumbersome to workaround.

Basically, with this patch you only get ISE if you are accessing _in a moment in time_ when you are not supposed to. Similarly, when calling `close`, you get ISE if you are closing a segment that is in a bad state (e.g. already closed, or temporarily locked by some native call). This feels consistent. The confinement exception was the confounding factor, I think, and a lot of checks against the exception message came from there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8865

From duke at openjdk.java.net  Wed May 25 10:52:50 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 25 May 2022 10:52:50 GMT
Subject: RFR: 8202449: overflow handling in Random.doubles [v3]
In-Reply-To: <S9k1SfnSYAzoiTlxdQ5fBpdMt4Uu8mlNWHSYJhWTI0g=.2e023744-7ed1-40a0-8075-31d8f2ede9ec@github.com>
References: <6OZGdr2SP8kDv1jsxupgndb3Lsbe62CQLlvhgHZNQAo=.1777192e-ba14-4bcc-9fea-a6a06d66543b@github.com>
 <S9k1SfnSYAzoiTlxdQ5fBpdMt4Uu8mlNWHSYJhWTI0g=.2e023744-7ed1-40a0-8075-31d8f2ede9ec@github.com>
Message-ID: <gqcgScog4cLb2ta8z0uBOdgj-wP-ad_nib0ceo5903U=.55c921df-a655-485a-b1a5-ec3296a14aa9@github.com>

On Tue, 24 May 2022 12:58:45 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Extend the range of Random.doubles(double, double) and similar methods.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8202449: overflow handling in Random.doubles

`Random.doubles(double, double)` and similar methods depend on `RandomGenerator.nextDouble(double, double)`.

Currently, this method is specified to throw when the range [origin, bound) given by the arguments is so large that its size (bound - origin) overflows. Since the proposed implementation doesn't suffer from this limitation, the specification needs to be modified, thus the need for a CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8791

From duke at openjdk.java.net  Wed May 25 11:11:18 2022
From: duke at openjdk.java.net (quincunx-45)
Date: Wed, 25 May 2022 11:11:18 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <glxyR5ydR2wrWs02IqqSlExZDKrVwyVnSt8OPySztzU=.c6a90d1a-6864-4b5a-9b30-4ed4ab27fbd7@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

Will the VM still exit if -XX:+ExitOnOutOfMemoryError/-XX:+CrashOnOutOfMemoryError/-XX:OnOutOfMemoryError/... was specified? I.e. can this change lead to more (avoidable) crashes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From peter.levart at gmail.com  Wed May 25 11:23:11 2022
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 May 2022 13:23:11 +0200
Subject: <T> Stream.fromForEach(Consumer<Consumer<T>>)
In-Reply-To: <52b1e6c5-ca0c-39ea-59ca-aa341f81bd4a@oracle.com>
References: <1144676012.11391840.1653173645995.JavaMail.zimbra@u-pem.fr>
 <52b1e6c5-ca0c-39ea-59ca-aa341f81bd4a@oracle.com>
Message-ID: <5f17a68b-d834-6131-2def-06d22e38ff24@gmail.com>

Hi,

On 23/05/2022 14:53, Brian Goetz wrote:
> ...
>
> Are there any useful Consumer<Consumer<T>> in the wild, that are 
> actually typed like that?? I doubt it (there are many things 
> convertible to it, though.)? Which suggests it might be fruitful to 
> define a FI:
>
> ??? interface PushSource<T> {
> ??????? void accept(Consumer<? extends Consumer<T>> pusher);
> ??? }
>
> ??? static<T> Stream<T> fromPush(PushSource<T> source) { ... }
>
> and Iterable::forEachRemaining and Optional::ifPresent will convert to 
> it.
>
>
...the PushSource would probably be just the following (a replacement 
for Consumer<Consumer<T>>):

 ??? interface PushSource<T> {
 ??????? void accept(Consumer<T> consumer);
 ??? }

The outer Consumer is not that problematic, IMO, since it is subject of 
conversion from any similar signature via lambdas/method references as 
easily as PushSource. The inner Consumer type is more problematic. For 
example, suppose one would have the following API:

 ??? interface Listener {
 ??????? void listen(String token);
 ??? }

 ??? record Parser(String text) {
 ??????? void parse(Listener listener) {
 ??????????? for (var token : text.split(" ")) {
 ??????????????? listener.listen(token);
 ??????????? }
 ??????? }
 ??? }


...to convert a Parser instance `parser` to a Stream of tokens, one 
would have to do something like this:

var parser = new Parser("1 2 3 4");

var stream = Stream.fromForEach(consumer -> parser.parse(consumer::accept));

...and then the type of stream would be inferred as Stream<Object>, not 
Stream<String> as one would like. Type hinting would be necessary:

var stream = Stream.<String>fromForEach(consumer -> 
parser.parse(consumer::accept));


I don't believe Java type system allows doing such things more elegantly.

One point to highlight is also that such method is only suitable for 
"finite" generators. A generator that emits infinite number of elements 
would have no way to stop emitting them although the resulting Stream 
was later shortened with .limit(max) or .takeWhile(predicate), ... Such 
Stream would never stop. This could be solved by a warning in the 
javadoc though. Or by something that project Loom could provide in the 
form of continuation?

As to the name, `generate` is taken by the generate(Supplier<T> 
supplier) form, but overload is technically possible, since it differs 
by parameters of unrelated type and number of parameters of the 
@FunctionalInterface methods (Supplier vs. Consumer). No conflicts 
should be expected.


Regards, Peter


From vkempik at openjdk.java.net  Wed May 25 11:29:55 2022
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Wed, 25 May 2022 11:29:55 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance()
In-Reply-To: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
Message-ID: <tKFGk_fGkqKwkFHEAByzsshPSabNQ_2QlTa67uTdH1w=.7fbb3691-0606-4419-abe7-da619059c73c@github.com>

On Fri, 20 May 2022 08:34:58 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. 
> 
> It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map.

Can some reviewer take a look at this please ?
This seems to be addressing rare corner issue.

-------------

Marked as reviewed by vkempik (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8803

From duke at openjdk.java.net  Wed May 25 11:40:04 2022
From: duke at openjdk.java.net (iaroslavski)
Date: Wed, 25 May 2022 11:40:04 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v12]
In-Reply-To: <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <RHUSEjQUIo3B58-BoqcgpH7Zx2ukEdbRqnbvdWD-3ZI=.320e6e9d-7980-415a-97e1-51341add55d5@github.com>
Message-ID: <_v7Qt2xs6HuGJ12lijGrBU0bBhmY1JxLS-G5aUJaorE=.094db93d-88b8-49b9-8032-892d6af97c86@github.com>

On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski <duke at openjdk.java.net> wrote:

>> Sorting:
>> 
>> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K)
>> - fix tryMergeRuns() to better handle case when the last run is a single element
>> - minor javadoc and comment changes
>> 
>> Testing:
>> - add new data inputs in tests for sorting
>> - add min/max/infinity values to float/double testing
>> - add tests for radix sort
>
> iaroslavski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>   
>   * Improved mixed insertion sort
>   * Optimized insertion sort
>   * Improved merging sort
>   * Optimized soring tests

This change will not lead to more crashes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3938

From jlahoda at openjdk.java.net  Wed May 25 11:59:20 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 25 May 2022 11:59:20 GMT
Subject: Integrated: 8262889: Compiler implementation for Record Patterns
In-Reply-To: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
Message-ID: <o9iUH7M8YGPmrCwuOKvsAjpY5rNw4ArsFF8SmeR0w0U=.2be89934-f8bc-46d7-bddc-3656bfa751fe@github.com>

On Tue, 3 May 2022 12:07:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 8262889: Compiler implementation for Record Patterns
> 
> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
> 
> There are two notable tricky parts:
> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
> 
> `MatchException` has been extended to cover additional cases related to record patterns.

This pull request has now been integrated.

Changeset: e9bddc18
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e9bddc18ab91c29d491b0e3bd145d641f6a62c5d
Stats:     2255 lines in 50 files changed: 2169 ins; 15 del; 71 mod

8262889: Compiler implementation for Record Patterns

Co-authored-by: Brian Goetz <briangoetz at openjdk.org>
Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: mcimadamore, vromero

-------------

PR: https://git.openjdk.java.net/jdk/pull/8516

From jlaskey at openjdk.java.net  Wed May 25 12:08:50 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 May 2022 12:08:50 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently
In-Reply-To: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
Message-ID: <dsXj2-jGMpKUjNCri3Ikh4k24M_vcAQ1mX5VdJ3H2IA=.993b7329-29b5-4ad0-ba6e-e4f24202a233@github.com>

On Wed, 25 May 2022 09:38:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
> 
> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
> 
> 
> Patched:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8881

From forax at openjdk.java.net  Wed May 25 13:21:04 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 May 2022 13:21:04 GMT
Subject: RFR: 8262889: Compiler implementation for Record Patterns [v7]
In-Reply-To: <vZkgWSviWgMBL3GDPgWtwtzoAIy_YDpd4ek5_eUiQps=.4786f5fe-6978-4d29-9f31-2c57c82a298a@github.com>
References: <n0eKd4k__O6KGknvxvCeIWaWRfVQGeVNMxQK4Hf96uI=.5f668c2d-aa25-4989-9b47-358046bee2d2@github.com>
 <vZkgWSviWgMBL3GDPgWtwtzoAIy_YDpd4ek5_eUiQps=.4786f5fe-6978-4d29-9f31-2c57c82a298a@github.com>
Message-ID: <77MgPFVlQc-JfSO9ZeTO8tq_pPPeFk2CDWvt0A-elvo=.08516a80-31c0-4164-aef9-5232f1e15217@github.com>

On Wed, 25 May 2022 04:20:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 8262889: Compiler implementation for Record Patterns
>> 
>> A first version of a patch that introduces record patterns into javac as a preview feature. For the specification, please see:
>> http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html
>> 
>> There are two notable tricky parts:
>> -in the parser, it was necessary to improve the `analyzePattern` method to handle nested/record patterns, while still keeping error recovery reasonable
>> -in the `TransPatterns`, the desugaring of the record patterns is very straightforward - effectivelly the record patterns are desugared into guards/conditions. This will likely be improved in some future version/preview
>> 
>> `MatchException` has been extended to cover additional cases related to record patterns.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into patterns-record-deconstruction3
>  - Post merge fix.
>  - Merge branch 'master' into patterns-record-deconstruction3
>  - Fixing (non-)exhaustiveness for enum.
>  - Merge branch 'type-pattern-third' into patterns-record-deconstruction3
>  - Merge branch 'master' into type-patterns-third
>  - Using Type.isRaw instead of checking the AST structure.
>  - Exhaustiveness should accept supertypes of the specified type.
>  - Renaming the features from deconstruction pattern to record pattern.
>  - Fixing guards after record patterns.
>  - ... and 24 more: https://git.openjdk.java.net/jdk/compare/742644e2...f49d3f0a

Yai ! champagne (at least virtual).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8516

From jvernee at openjdk.java.net  Wed May 25 13:33:00 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 May 2022 13:33:00 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently
In-Reply-To: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
Message-ID: <JFlQrIKrh2ENB8Ixrhh3yVIJAQVjm434f4TjFtKBt58=.ec314a10-ae34-4a21-870a-a3275e2e0d16@github.com>

On Wed, 25 May 2022 09:38:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
> 
> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
> 
> 
> Patched:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op

src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 239:

> 237:             for (int i = 0; i < b23456.length; i++) {
> 238:                 int b = b23456[i] & 0xFF;
> 239:                 bitset |= b;

Looks like `b` is always truncated. I wonder what happens if the ints in this array are larger than a byte (which seems to be possible in e.g. the case of argument positions). Some higher order bits might be dropped, but the resulting `b` might only have the least significant 4 bits set.

I think the untruncated value should be used to compute the bitset? `butset |= b23456[i]`? Then the `inRange` check should reject that case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8881

From jvernee at openjdk.java.net  Wed May 25 13:33:02 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 May 2022 13:33:02 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently
In-Reply-To: <77uLIBAiEmsqOfuI3vYK_RjSKQaW5HSl5OYJ3ezCChY=.59b4e01f-4edf-4d7b-ae85-c6e182a2c709@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
 <JFlQrIKrh2ENB8Ixrhh3yVIJAQVjm434f4TjFtKBt58=.ec314a10-ae34-4a21-870a-a3275e2e0d16@github.com>
 <77uLIBAiEmsqOfuI3vYK_RjSKQaW5HSl5OYJ3ezCChY=.59b4e01f-4edf-4d7b-ae85-c6e182a2c709@github.com>
Message-ID: <MlXhO-K1oTKKk9zvUPkxb9jHA2Z1RVY8Lw5kcz0y3R0=.cb90fed8-65c8-414c-8169-47e363e94239@github.com>

On Wed, 25 May 2022 13:28:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 239:
>> 
>>> 237:             for (int i = 0; i < b23456.length; i++) {
>>> 238:                 int b = b23456[i] & 0xFF;
>>> 239:                 bitset |= b;
>> 
>> Looks like `b` is always truncated. I wonder what happens if the ints in this array are larger than a byte (which seems to be possible in e.g. the case of argument positions). Some higher order bits might be dropped, but the resulting `b` might only have the least significant 4 bits set.
>> 
>> I think the untruncated value should be used to compute the bitset? `butset |= b23456[i]`? Then the `inRange` check should reject that case.
>
> Maybe not... argument positions should fit in a byte as well. But, maybe there are other problematic cases? Or are the ints guaranteed to fit in a byte?

Maybe an `assert b == b23456[i]` would be nice here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8881

From jvernee at openjdk.java.net  Wed May 25 13:33:02 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 May 2022 13:33:02 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently
In-Reply-To: <JFlQrIKrh2ENB8Ixrhh3yVIJAQVjm434f4TjFtKBt58=.ec314a10-ae34-4a21-870a-a3275e2e0d16@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
 <JFlQrIKrh2ENB8Ixrhh3yVIJAQVjm434f4TjFtKBt58=.ec314a10-ae34-4a21-870a-a3275e2e0d16@github.com>
Message-ID: <77uLIBAiEmsqOfuI3vYK_RjSKQaW5HSl5OYJ3ezCChY=.59b4e01f-4edf-4d7b-ae85-c6e182a2c709@github.com>

On Wed, 25 May 2022 13:27:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
>> 
>> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
>> 
>> Baseline:
>> 
>> Benchmark                                                      Mode  Cnt     Score     Error   Units
>> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
>> 
>> 
>> Patched:
>> 
>> Benchmark                                                      Mode  Cnt     Score     Error   Units
>> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op
>
> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 239:
> 
>> 237:             for (int i = 0; i < b23456.length; i++) {
>> 238:                 int b = b23456[i] & 0xFF;
>> 239:                 bitset |= b;
> 
> Looks like `b` is always truncated. I wonder what happens if the ints in this array are larger than a byte (which seems to be possible in e.g. the case of argument positions). Some higher order bits might be dropped, but the resulting `b` might only have the least significant 4 bits set.
> 
> I think the untruncated value should be used to compute the bitset? `butset |= b23456[i]`? Then the `inRange` check should reject that case.

Maybe not... argument positions should fit in a byte as well. But, maybe there are other problematic cases? Or are the ints guaranteed to fit in a byte?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8881

From redestad at openjdk.java.net  Wed May 25 13:43:56 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 25 May 2022 13:43:56 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently
In-Reply-To: <MlXhO-K1oTKKk9zvUPkxb9jHA2Z1RVY8Lw5kcz0y3R0=.cb90fed8-65c8-414c-8169-47e363e94239@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
 <JFlQrIKrh2ENB8Ixrhh3yVIJAQVjm434f4TjFtKBt58=.ec314a10-ae34-4a21-870a-a3275e2e0d16@github.com>
 <77uLIBAiEmsqOfuI3vYK_RjSKQaW5HSl5OYJ3ezCChY=.59b4e01f-4edf-4d7b-ae85-c6e182a2c709@github.com>
 <MlXhO-K1oTKKk9zvUPkxb9jHA2Z1RVY8Lw5kcz0y3R0=.cb90fed8-65c8-414c-8169-47e363e94239@github.com>
Message-ID: <Q5yL-MeVW2lan1sI4FJB9yiloqPD9yiBLu2MZ0wUQeU=.9c0ef6d1-1454-49c9-a6fb-42b876adc498@github.com>

On Wed, 25 May 2022 13:30:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maybe not... argument positions should fit in a byte as well. But, maybe there are other problematic cases? Or are the ints guaranteed to fit in a byte?
>
> Maybe an `assert b == b23456[i]` would be nice here.

All usage implies the int is an argument position, which by spec is constrained to be in the 0-255 range. But surely checking or asserting shouldn't hurt.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8881

From jvernee at openjdk.java.net  Wed May 25 13:43:56 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 May 2022 13:43:56 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently
In-Reply-To: <Q5yL-MeVW2lan1sI4FJB9yiloqPD9yiBLu2MZ0wUQeU=.9c0ef6d1-1454-49c9-a6fb-42b876adc498@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
 <JFlQrIKrh2ENB8Ixrhh3yVIJAQVjm434f4TjFtKBt58=.ec314a10-ae34-4a21-870a-a3275e2e0d16@github.com>
 <77uLIBAiEmsqOfuI3vYK_RjSKQaW5HSl5OYJ3ezCChY=.59b4e01f-4edf-4d7b-ae85-c6e182a2c709@github.com>
 <MlXhO-K1oTKKk9zvUPkxb9jHA2Z1RVY8Lw5kcz0y3R0=.cb90fed8-65c8-414c-8169-47e363e94239@github.com>
 <Q5yL-MeVW2lan1sI4FJB9yiloqPD9yiBLu2MZ0wUQeU=.9c0ef6d1-1454-49c9-a6fb-42b876adc498@github.com>
Message-ID: <IZqgJ3oM8i8P8mPmONrNkji09YpnMsj7gkBxggx1K_g=.e9455028-71b0-4ff3-9700-29637a7e73f3@github.com>

On Wed, 25 May 2022 13:37:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Maybe an `assert b == b23456[i]` would be nice here.
>
> All usage implies the int is an argument position, which by spec is constrained to be in the 0-255 range. But surely checking or asserting shouldn't hurt.

Yes, please. IMHO it makes it clear that that is the assumption of this code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8881

From raffaello.giulietti at oracle.com  Wed May 25 13:46:39 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 25 May 2022 13:46:39 +0000
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
In-Reply-To: <381e0979-ae04-63e5-df58-3cdb96bb8797@oracle.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <381e0979-ae04-63e5-df58-3cdb96bb8797@oracle.com>
Message-ID: <BY5PR10MB400244A685D7CC87419F276A87D79@BY5PR10MB4002.namprd10.prod.outlook.com>

The motivation behind this PR is not driven by pattern matching: John Rose (the reporter of the JBS issue) is concerned about having safer casts that, in addition, can be JITted to efficient code.

But I get your point that having non-throwing tests better serves pattern matching. However, I?m not sure that pattern matching alone would remove the more general need for the proposed methods.

As for the controversial question about -0.0, as you note any proposal will kind of suck. With ?safer? cast methods we can have two (or even more) variants.

In the context of primitive pattern matching (including the relevant material in the JLS), however, it would be probably much simpler to allow for matches between integral types on one side and for matches between floating-point types on the other side, but not a mix. The nuisance with -0.0 and other special values would disappear altogether.

Thus, while examples like
    if (anIntExpression instanceof byte b)
and
    if (aDoubleExpression instanceof float f)
make perfect sense, would an example like
    if (aDoubleExpression instanceof short s)
be pragmatically reasonable?

IIRC, the discussions about ?Primitive type patterns? and ?Evolving past reference type patterns? in the amber-spec-experts mailing list of April 2022 don?t even mention the mixed integral/floating-point case.


Greetings
Raffaello


From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Brian Goetz <brian.goetz at oracle.com>
Date: Tuesday, 24 May 2022 at 00:09
To: Raffaello Giulietti <duke at openjdk.java.net>, core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
This work is quite timely as we are now paving the way for primitive
type patterns over in Project Amber, and also has a nontrivial
connection with Valhalla.  If you'll pardon a brief digression...

Instanceof and casting work together in a familiar way: before you cast,
you first ask instanceof -- but this is restricted currently to
reference types.  But the pattern is obvious: instanceof is the
precondition check for casting, which asks: "If I made this cast, would
I like the answer."  There are currently two reasons to not like the
answer: a CCE, or the operand is null (because, even though the cast
would succeed, if you tried to use it as a member of that type, you
wouldn't like the answer then.)

If we wanted to extend `instanceof` to primitive types, we are asking
the same question: if I were to cast to this type, would I like the
answer.  And casts involving primitives give us two more reasons to not
like the answer: an NPE (due to unboxing), or loss of precision.  Which
means that we have to specify in JLS 5.1 what cast with loss of
precision means.  At the very least, we will want to align this work
with that; the asXExact should be able to say "throws if the cast would
lose precision", where "lose precision" is precisely defined by the JLS.

Separately, Project Valhalla will let us define new primitive-like
types, such as HalfFloat and SuperLong. Conversions between primitives
are currently specified in a complex table in JLS 5.1.  But surely we
will want to support primitive widening conversions between HalfFloat
and float (somehow; how we do this is a separate discussion.)  Which
brings us back to pattern matching; narrowing casts are inherently
partial, and declared patterns bring partiality into the "return type",
and are the natural way (when we have it) to express things like "cast,
but fail if you can't do so safely". This is preferable to throwing
(which currently is the our choice.)  So it might be a little
unfortunate to introduce throwing toXExactly now and then have to
introduce separate patterns which signal precision loss by match
failure.  (Though that's not the end of the world if there is some
duplication.)

What this says is that the current proposal of toXExact is not the
primitive, because we probably wouldn't want to implement a pattern in
terms of the throwing version.

Converting from float/double to integral types is particularly tricky
with -0.0.  Both answers kind of suck.  (This is a familiar situation,
and these can be very difficult to resolve, as for each position,
*someone* has decided the other position is untenable.)  I understand
the rationale behind Michael H's "but its not exact", but let's not
pretend one answer is good and the other sucks -- they both suck, and
therefore the decision can be made on other factors.

So I have a few new wrinkles to add to the story:

  - We should wait until we have candidate JLS text for "cast conversion
without loss of precision", and ensure the two are consistent, before
pushing;
  - I not quite comfortable with settling the -0.0 issue just yet, there
are some other explorations to complete first;
  - We should be prepared for the fact that we will, sometime soon, have
to implement this whole set again as patterns that do not throw.








On 5/5/2022 6:18 AM, Raffaello Giulietti wrote:
> Add a family of "safe" cast methods.
>
> -------------
>
> Commit messages:
>   - 8279986: methods Math::asXExact for safely checked primitive casts
>   - 8279986: methods Math::asXExact for safely checked primitive casts
>   - 8279986: methods Math::asXExact for safely checked primitive casts
>
> Changes:https://git.openjdk.java.net/jdk/pull/8548/files
>   Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=8548&range=00
>    Issue:https://bugs.openjdk.java.net/browse/JDK-8279986
>    Stats: 615 lines in 2 files changed: 609 ins; 0 del; 6 mod
>    Patch:https://git.openjdk.java.net/jdk/pull/8548.diff
>    Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/8548/head:pull/8548
>
> PR:https://git.openjdk.java.net/jdk/pull/8548

From jvernee at openjdk.java.net  Wed May 25 13:51:02 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 May 2022 13:51:02 GMT
Subject: RFR: 8287244: Add bound check in indexed memory access var handle
 [v3]
In-Reply-To: <UnFG9eqceJSeNXMvCzHwf4SmJb6t9yo6ZToIOdh8H8o=.ee018132-d395-466b-995a-2dd28b0e67b9@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
 <UnFG9eqceJSeNXMvCzHwf4SmJb6t9yo6ZToIOdh8H8o=.ee018132-d395-466b-995a-2dd28b0e67b9@github.com>
Message-ID: <vi5kWVtYgD81HuW4wJh9cSL1i9Zj00lCXvdR495fZqE=.6e55a001-bf1f-4d88-a08c-26773bdc5375@github.com>

On Tue, 24 May 2022 18:15:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Constructing indexed var handles using the `MemoryLayout` API produces `VarHandle` which do not check the input indices for out-of-bounds conditions.
>> While this can never result in a VM crash (after all the memory segment will protect against "true" OOB access), it is still possible for an access expression to refer to parts of a segment that are logically unrelated.
>> 
>> This patch adds a "logical" bound check to all indexed var handles generated using the layout API.
>> Benchmarks are not affected by the check. Users are still able to create custom "unchecked" var handles, using the combinator API in `MethodHandles`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Very nice!

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8868

From redestad at openjdk.java.net  Wed May 25 14:03:41 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 25 May 2022 14:03:41 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently [v2]
In-Reply-To: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
Message-ID: <M6YLpZxI-AlFVtGOo59FqZ6ArqKASj23bXkGEvfz_6Q=.14a8bd93-b367-447c-a830-d083f36f8cf7@github.com>

> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
> 
> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
> 
> 
> Patched:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments, fix unsafe shift, rework and remove ofBothArrays

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8881/files
  - new: https://git.openjdk.java.net/jdk/pull/8881/files/001e9d16..2be3b25c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8881&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8881&range=00-01

  Stats: 86 lines in 2 files changed: 50 ins; 12 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8881.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8881/head:pull/8881

PR: https://git.openjdk.java.net/jdk/pull/8881

From redestad at openjdk.java.net  Wed May 25 14:13:52 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 25 May 2022 14:13:52 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently [v3]
In-Reply-To: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
Message-ID: <N7FLxaPZtjFR0h5_KeYIhsWswnopoSuX06Ir-Ba8GyY=.691d4e2c-2840-40f1-82cc-fe9487bcd1a8@github.com>

> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
> 
> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
> 
> 
> Patched:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Missed correctly taking b1 into account in of(byte, int, int...) (java/lang/String/concat/ImplicitStringConcatShapes.java test failure)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8881/files
  - new: https://git.openjdk.java.net/jdk/pull/8881/files/2be3b25c..612b4ece

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8881&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8881&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8881.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8881/head:pull/8881

PR: https://git.openjdk.java.net/jdk/pull/8881

From jvernee at openjdk.java.net  Wed May 25 14:13:55 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 May 2022 14:13:55 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently [v2]
In-Reply-To: <M6YLpZxI-AlFVtGOo59FqZ6ArqKASj23bXkGEvfz_6Q=.14a8bd93-b367-447c-a830-d083f36f8cf7@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
 <M6YLpZxI-AlFVtGOo59FqZ6ArqKASj23bXkGEvfz_6Q=.14a8bd93-b367-447c-a830-d083f36f8cf7@github.com>
Message-ID: <B5VE-R4DERgajToQFpNWF74oOBTHKQXrwW0oIPsLUH4=.19ac4299-51d1-4bfa-8ea8-5e847fa93be7@github.com>

On Wed, 25 May 2022 14:03:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
>> 
>> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
>> 
>> Baseline:
>> 
>> Benchmark                                                      Mode  Cnt     Score     Error   Units
>> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
>> 
>> 
>> Patched:
>> 
>> Benchmark                                                      Mode  Cnt     Score     Error   Units
>> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments, fix unsafe shift, rework and remove ofBothArrays

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8881

From plevart at openjdk.java.net  Wed May 25 14:43:57 2022
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 25 May 2022 14:43:57 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance()
In-Reply-To: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
Message-ID: <_6tzEtf0vVpRlzeVthCLiLuVCoK2EhgKxbHe8WU-TV4=.ae1222b5-20af-4634-9412-c17d6d161bd3@github.com>

On Fri, 20 May 2022 08:34:58 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. 
> 
> It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map.

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 113:

> 111:             CgroupInfo anyController = infos.values().iterator().next();
> 112:             CgroupSubsystem subsystem = CgroupV2Subsystem.getInstance(anyController);
> 113:             return subsystem != null ? new CgroupMetrics(subsystem) : null;

Looking at implementation of CgroupV2Subsystem.getInstance(...), it seems that it always returns != null ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From plevart at openjdk.java.net  Wed May 25 14:50:55 2022
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 25 May 2022 14:50:55 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance()
In-Reply-To: <_6tzEtf0vVpRlzeVthCLiLuVCoK2EhgKxbHe8WU-TV4=.ae1222b5-20af-4634-9412-c17d6d161bd3@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
 <_6tzEtf0vVpRlzeVthCLiLuVCoK2EhgKxbHe8WU-TV4=.ae1222b5-20af-4634-9412-c17d6d161bd3@github.com>
Message-ID: <zEp9jO73YLvh-Hc0JHNaOgj-HUXCVVegCu-ug9wwr1w=.7c897d26-7a10-41fd-b1dd-bd1a04b3ad1d@github.com>

On Wed, 25 May 2022 14:39:42 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. 
>> 
>> It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map.
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 113:
> 
>> 111:             CgroupInfo anyController = infos.values().iterator().next();
>> 112:             CgroupSubsystem subsystem = CgroupV2Subsystem.getInstance(anyController);
>> 113:             return subsystem != null ? new CgroupMetrics(subsystem) : null;
> 
> Looking at implementation of CgroupV2Subsystem.getInstance(...), it seems that it always returns != null ...

`CgroupV1Subsystem.getInstance(...)` also claims that it never returns `null`, but has a code-path that actually returns `null` (when there is no active controller). Is this a possible outcome?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From brian.goetz at oracle.com  Wed May 25 15:12:02 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 25 May 2022 11:12:02 -0400
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
In-Reply-To: <BY5PR10MB400244A685D7CC87419F276A87D79@BY5PR10MB4002.namprd10.prod.outlook.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <381e0979-ae04-63e5-df58-3cdb96bb8797@oracle.com>
 <BY5PR10MB400244A685D7CC87419F276A87D79@BY5PR10MB4002.namprd10.prod.outlook.com>
Message-ID: <0fd284ab-a297-4f46-5e2c-b461af6cd1d7@oracle.com>


> Themotivation behind this PR isnot driven by pattern matching:John 
> Rose (the reporter of the JBS issue) is concerned about having safer 
> casts that, in addition, can be JITted to efficient code.
>

Yes, of course.? But also, as the platform evolves, it often happens 
that the same issues arises in separate places.? It would be terrible if 
asXExact had a different opinion of what could be converted exactly to 
an int, from the language's `instanceof int`. And similarly, it would be 
unfortunate if the semantics were driven by nothing more than "who got 
there first."? So we frequently discover things that we thought were 
independent increments of functionality, that turn out to want to be 
co-designed with other things, even those not known at the time we 
started.? This is just how this game works.

> But I get your point that having non-throwing testsbetter serves 
> pattern matching.However, I?m not sure that pattern matching alone 
> would remove the more general need for the proposed methods.
>

Yes, not sure either.? The game here is "find the primitive"; our first 
move in this game is not always the right one.? So let's figure it out.

> As for the controversial question about -0.0, as you note any proposal 
> will kind of suck. With ?safer? cast methods we can have two (or even 
> more) variants.
>

Also, small changes in terminology can subtly bias our answer. Words 
like "exact", "information-preserving", "loss of precision", "safe", 
etc, all seem to circle the same concept, but the exact choice of 
terminology -- often made at random at the beginning of an investigation 
-- can bias us one way or the other.? (Concrete illustration: converting 
-0.0 to 0 seems questionable when your rule is "no loss of information", 
but seems more ambiguous when your rule is "safe".)

> In the context of primitive pattern matching (including the relevant 
> material in the JLS), however, it would be probably much simpler to 
> allow for matches between integral types on one side and for matches 
> between floating-point types on the other side, but not a mix. The 
> nuisance with -0.0 and other special values would disappear altogether.
>

That was my first thought as well, but then I had second thoughts, as 
this seemed like wishful thinking.? If we are willing to say:

 ??? long x = 7;
 ??? if (x instanceof int) { /* yes, it is */ }

then it may seem quite odd to not also say

 ??? double x = 7.0;
 ??? if (x instanceof int) { /* this too? */ }

Because, the natural way to interpret the first is "is the value on the 
left representable in the type on the right."? Clearly 7 is 
representable as an int.? But so is 7.0; we lose nothing going from 
double 7.0 -> int 7 -> double 7.0.? And whoosh, now we're sucked into 
belly of the machine, staring down -0.0 and NaN other abominations, 
questioning our life choices.

That's not to say that your initial thought is wrong, just that it will 
be surprising if we go that way.? Maybe surprises are inevitable; maybe 
this is the least bad of possible surprises.? We should eliminate the 
"maybes" from this analysis first, though, before deciding.

> Thus, while examples like
>
> ??? if (anIntExpression instanceof byte b)
>
> and
>
> ??? if (aDoubleExpression instanceof float f)
>
> make perfect sense, would an example like
> ??? if (aDoubleExpression instanceof short s)
>
> be pragmatically reasonable?
>
> IIRC, the discussions about ?Primitive type patterns? and ?Evolving 
> past reference type patterns? in the amber-spec-experts mailing list 
> of April 2022 don?t even mention the mixed integral/floating-point case.
>

Correct, we hadn't gotten there yet, we were still trying to wrap our 
heads around how it should work in the easier cases.


From brian.goetz at oracle.com  Wed May 25 15:18:26 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 25 May 2022 11:18:26 -0400
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
In-Reply-To: <BY5PR10MB400244A685D7CC87419F276A87D79@BY5PR10MB4002.namprd10.prod.outlook.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <381e0979-ae04-63e5-df58-3cdb96bb8797@oracle.com>
 <BY5PR10MB400244A685D7CC87419F276A87D79@BY5PR10MB4002.namprd10.prod.outlook.com>
Message-ID: <fcdd9f29-aaa4-84d2-6d8e-7d7b5493aae4@oracle.com>

Another way to evaluate answers here is: are we inventing new relations, 
or merely clarifying old ones?? The latter is often more desirable.

For example, we might say that x:X can be converted exactly to Y, for 
primitive X and Y, iff:

 ??? eq( (X) (Y) x, x )

where `eq` is `==` for non-floating primitive types, and derived from 
Float::compare and Double::compare for floating point. This means we are 
not inventing any new conversions or comparisons, but merely combining 
ones we already have in the language/platform in a convenient way.

Do the toXExact methods you've defined have this characteristic?

(Though, while this is often the best starting place, it is not always a 
slam-dunk answer; sometimes there are good reasons to depart from 
existing relations, but we should be explicit about what those are.)



On 5/25/2022 9:46 AM, Raffaello Giulietti wrote:
>
> Themotivation behind this PR isnot driven by pattern matching:John 
> Rose (the reporter of the JBS issue) is concerned about having safer 
> casts that, in addition, can be JITted to efficient code.
>
> But I get your point that having non-throwing testsbetter serves 
> pattern matching.However, I?m not sure that pattern matching alone 
> would remove the more general need for the proposed methods.
>
> As for the controversial question about -0.0, as you note any proposal 
> will kind of suck. With ?safer? cast methods we can have two (or even 
> more) variants.
>
> In the context of primitive pattern matching (including the relevant 
> material in the JLS), however, it would be probably much simpler to 
> allow for matches between integral types on one side and for matches 
> between floating-point types on the other side, but not a mix. The 
> nuisance with -0.0 and other special values would disappear altogether.
>
> Thus, while examples like
>
> ??? if (anIntExpression instanceof byte b)
>
> and
>
> ??? if (aDoubleExpression instanceof float f)
>
> make perfect sense, would an example like
> ??? if (aDoubleExpression instanceof short s)
>
> be pragmatically reasonable?
>
> IIRC, the discussions about ?Primitive type patterns? and ?Evolving 
> past reference type patterns? in the amber-spec-experts mailing list 
> of April 2022 don?t even mention the mixed integral/floating-point case.
>
> Greetings
> Raffaello
>
> *From: *core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf 
> of Brian Goetz <brian.goetz at oracle.com>
> *Date: *Tuesday, 24 May 2022 at 00:09
> *To: *Raffaello Giulietti <duke at openjdk.java.net>, 
> core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
> *Subject: *Re: RFR: 8279986: methods Math::asXExact for safely checked 
> primitive casts
>
> This work is quite timely as we are now paving the way for primitive
> type patterns over in Project Amber, and also has a nontrivial
> connection with Valhalla.? If you'll pardon a brief digression...
>
> Instanceof and casting work together in a familiar way: before you cast,
> you first ask instanceof -- but this is restricted currently to
> reference types.? But the pattern is obvious: instanceof is the
> precondition check for casting, which asks: "If I made this cast, would
> I like the answer."? There are currently two reasons to not like the
> answer: a CCE, or the operand is null (because, even though the cast
> would succeed, if you tried to use it as a member of that type, you
> wouldn't like the answer then.)
>
> If we wanted to extend `instanceof` to primitive types, we are asking
> the same question: if I were to cast to this type, would I like the
> answer.? And casts involving primitives give us two more reasons to not
> like the answer: an NPE (due to unboxing), or loss of precision.? Which
> means that we have to specify in JLS 5.1 what cast with loss of
> precision means.? At the very least, we will want to align this work
> with that; the asXExact should be able to say "throws if the cast would
> lose precision", where "lose precision" is precisely defined by the JLS.
>
> Separately, Project Valhalla will let us define new primitive-like
> types, such as HalfFloat and SuperLong. Conversions between primitives
> are currently specified in a complex table in JLS 5.1. But surely we
> will want to support primitive widening conversions between HalfFloat
> and float (somehow; how we do this is a separate discussion.)? Which
> brings us back to pattern matching; narrowing casts are inherently
> partial, and declared patterns bring partiality into the "return type",
> and are the natural way (when we have it) to express things like "cast,
> but fail if you can't do so safely". This is preferable to throwing
> (which currently is the our choice.)? So it might be a little
> unfortunate to introduce throwing toXExactly now and then have to
> introduce separate patterns which signal precision loss by match
> failure.? (Though that's not the end of the world if there is some
> duplication.)
>
> What this says is that the current proposal of toXExact is not the
> primitive, because we probably wouldn't want to implement a pattern in
> terms of the throwing version.
>
> Converting from float/double to integral types is particularly tricky
> with -0.0.? Both answers kind of suck.? (This is a familiar situation,
> and these can be very difficult to resolve, as for each position,
> *someone* has decided the other position is untenable.)? I understand
> the rationale behind Michael H's "but its not exact", but let's not
> pretend one answer is good and the other sucks -- they both suck, and
> therefore the decision can be made on other factors.
>
> So I have a few new wrinkles to add to the story:
>
> ??- We should wait until we have candidate JLS text for "cast conversion
> without loss of precision", and ensure the two are consistent, before
> pushing;
> ??- I not quite comfortable with settling the -0.0 issue just yet, there
> are some other explorations to complete first;
> ??- We should be prepared for the fact that we will, sometime soon, have
> to implement this whole set again as patterns that do not throw.
>
>
>
>
>
>
>
>
> On 5/5/2022 6:18 AM, Raffaello Giulietti wrote:
> > Add a family of "safe" cast methods.
> >
> > -------------
> >
> > Commit messages:
> >?? - 8279986: methods Math::asXExact for safely checked primitive casts
> >?? - 8279986: methods Math::asXExact for safely checked primitive casts
> >?? - 8279986: methods Math::asXExact for safely checked primitive casts
> >
> > Changes:https://git.openjdk.java.net/jdk/pull/8548/files
> > Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=8548&range=00
> > Issue:https://bugs.openjdk.java.net/browse/JDK-8279986
> >??? Stats: 615 lines in 2 files changed: 609 ins; 0 del; 6 mod
> > Patch:https://git.openjdk.java.net/jdk/pull/8548.diff
> >??? Fetch: git fetchhttps://git.openjdk.java.net/jdk 
> pull/8548/head:pull/8548
> >
> > PR:https://git.openjdk.java.net/jdk/pull/8548
>

From iklam at openjdk.java.net  Wed May 25 15:51:06 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 25 May 2022 15:51:06 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v3]
In-Reply-To: <RV2RrYZIThRLap-I9rJS4hitj4OHW5q6iBmABrAaWoE=.76f9fa14-987c-4e94-a94a-671a7e40c391@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
 <EisSyVHbjSUIyBsszUjM97_OwD8Jt2cBIzSpXZpAEu8=.c62a5c40-e727-4f27-96d5-c7e5087725f0@github.com>
 <ddUidECANrWtWa9L99eKLekZaltBGZh07WPdZwadEpI=.adb52b74-6624-4b1f-bf7b-a62aef5b9aeb@github.com>
 <pa4qHV9MGgYhWwOnMydw25tUfRFh7ozC-sez1mfPHIE=.126361a3-4b05-47e9-ab1a-f8589d31df2d@github.com>
 <RV2RrYZIThRLap-I9rJS4hitj4OHW5q6iBmABrAaWoE=.76f9fa14-987c-4e94-a94a-671a7e40c391@github.com>
Message-ID: <Kxfj9YHxg5Eg56vt8L5KGyXP4yGCiZBpiZr_65mzzOg=.bc4fb9d9-b97c-4a19-9a99-b7ec8dc1caea@github.com>

On Tue, 24 May 2022 19:49:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> My bad. How about `Intentional incomplete switch. There are ...`? Anyway, why is the empty `default` case needed other than for the comment?
>
> To me, the `default:` switch is a clear indication that "everything else comes here". So you won't be confused whether the comment is related to the last line just above the comment.

If you don't like the `default:` coding style, how about this:


switch (info.getName()) {
// Only the following controllers are important to Java. All
// other controllers (such as freezer) are ignored and
// are not considered in the checks below for
// anyCgroupsV1Controller/anyCgroupsV1Controller.
case CPU_CTRL:      infos.put(CPU_CTRL, info); break;
case CPUACCT_CTRL:  infos.put(CPUACCT_CTRL, info); break;
case CPUSET_CTRL:   infos.put(CPUSET_CTRL, info); break;
case MEMORY_CTRL:   infos.put(MEMORY_CTRL, info); break;
case BLKIO_CTRL:    infos.put(BLKIO_CTRL, info); break;
case PIDS_CTRL:     infos.put(PIDS_CTRL, info); break;
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From iklam at openjdk.java.net  Wed May 25 15:51:04 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 25 May 2022 15:51:04 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v3]
In-Reply-To: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
Message-ID: <vjsUBMDkqQG79SPFt2ft-uTUdI5RhKjc94T3HwX1omA=.7923adc9-f111-4aab-b860-6ccd88019ff0@github.com>

> This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode.
> 
> The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1).
> 
> However, the "hybrid checks" only considers the following controllers that Java cares about:
> 
> - cpu
> - cpuacct
> - cpuset
> - blkio
> - memory
> - pids
> 
> If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert.
> 
> 
> $ cat /proc/self/cgroup
> 1:freezer:/
> 0::/user.slice/user-1001.slice/session-85.scope
> 
> 
> The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  fixed comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8858/files
  - new: https://git.openjdk.java.net/jdk/pull/8858/files/1f17b6e8..9134182e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=01-02

  Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8858.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8858/head:pull/8858

PR: https://git.openjdk.java.net/jdk/pull/8858

From sgehwolf at openjdk.java.net  Wed May 25 15:53:20 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 25 May 2022 15:53:20 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v3]
In-Reply-To: <f2VI8ODNEnRwjN1oZKd0aGc3UwuwT3yMijcxYLSyetk=.2763038e-74a3-4ab0-8878-9dd42e01e58d@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
 <EisSyVHbjSUIyBsszUjM97_OwD8Jt2cBIzSpXZpAEu8=.c62a5c40-e727-4f27-96d5-c7e5087725f0@github.com>
 <ddUidECANrWtWa9L99eKLekZaltBGZh07WPdZwadEpI=.adb52b74-6624-4b1f-bf7b-a62aef5b9aeb@github.com>
 <pa4qHV9MGgYhWwOnMydw25tUfRFh7ozC-sez1mfPHIE=.126361a3-4b05-47e9-ab1a-f8589d31df2d@github.com>
 <RV2RrYZIThRLap-I9rJS4hitj4OHW5q6iBmABrAaWoE=.76f9fa14-987c-4e94-a94a-671a7e40c391@github.com>
 <f2VI8ODNEnRwjN1oZKd0aGc3UwuwT3yMijcxYLSyetk=.2763038e-74a3-4ab0-8878-9dd42e01e58d@github.com>
Message-ID: <Y2V_Ztdt9jwb8wN0Q8Xtvg7VFDfzpDVv2RPLRz_uBO4=.25caf9ad-44a0-4a7e-9816-4e90cb58030c@github.com>

On Wed, 25 May 2022 08:40:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> If you don't like the `default:` coding style, how about this:
>> 
>> 
>> switch (info.getName()) {
>> // Only the following controllers are important to Java. All
>> // other controllers (such as freezer) are ignored and
>> // are not considered in the checks below for
>> // anyCgroupsV1Controller/anyCgroupsV1Controller.
>> case CPU_CTRL:      infos.put(CPU_CTRL, info); break;
>> case CPUACCT_CTRL:  infos.put(CPUACCT_CTRL, info); break;
>> case CPUSET_CTRL:   infos.put(CPUSET_CTRL, info); break;
>> case MEMORY_CTRL:   infos.put(MEMORY_CTRL, info); break;
>> case BLKIO_CTRL:    infos.put(BLKIO_CTRL, info); break;
>> case PIDS_CTRL:     infos.put(PIDS_CTRL, info); break;
>> }
>
> It confused me, fwiw. Anyway up to you. It's not super important.

works for me. +1. Note the typo `anyCgroupsV1Controller/anyCgroupsV2Controller` not **V1** twice.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From mkartashev at openjdk.java.net  Wed May 25 15:57:57 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Wed, 25 May 2022 15:57:57 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance()
In-Reply-To: <zEp9jO73YLvh-Hc0JHNaOgj-HUXCVVegCu-ug9wwr1w=.7c897d26-7a10-41fd-b1dd-bd1a04b3ad1d@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
 <_6tzEtf0vVpRlzeVthCLiLuVCoK2EhgKxbHe8WU-TV4=.ae1222b5-20af-4634-9412-c17d6d161bd3@github.com>
 <zEp9jO73YLvh-Hc0JHNaOgj-HUXCVVegCu-ug9wwr1w=.7c897d26-7a10-41fd-b1dd-bd1a04b3ad1d@github.com>
Message-ID: <6_iySZ7wuU98uaAd2Pw3DqFn7cCr4ex8r3zb-vX7N4o=.0485c0d1-6d68-4da9-939e-6d7a494adaad@github.com>

On Wed, 25 May 2022 14:47:06 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 113:
>> 
>>> 111:             CgroupInfo anyController = infos.values().iterator().next();
>>> 112:             CgroupSubsystem subsystem = CgroupV2Subsystem.getInstance(anyController);
>>> 113:             return subsystem != null ? new CgroupMetrics(subsystem) : null;
>> 
>> Looking at implementation of CgroupV2Subsystem.getInstance(...), it seems that it always returns != null ...
>
> `CgroupV1Subsystem.getInstance(...)` also claims that it never returns `null`, but has a code-path that actually returns `null` (when there is no active controller). Is this a possible outcome?

@plevart Are you asking about the reason for the crash or about the changes?
If it's the former, then I believe that the crash comes not from `getInstance()` returning `null`, but from further down the stack because `null` is being passed to `getInstance()`. I could be wrong in interpreting the report, though.

If the question's about the changes, then those are restricted to CgroupV2, so I'm not sure how `CgroupV1Subsystem.getInstance(...)` returning null is related. FWIW, I also don't think we are going to get here if there are no active controllers. There's this code a few lines above:

if (!result.isAnyControllersEnabled()) {
            return null;
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From raffaello.giulietti at oracle.com  Wed May 25 16:14:06 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 25 May 2022 16:14:06 +0000
Subject: RFR: 8279986: methods Math::asXExact for safely checked primitive
 casts
In-Reply-To: <fcdd9f29-aaa4-84d2-6d8e-7d7b5493aae4@oracle.com>
References: <uBItJPyPmTs5mhb4_B4JNUwxcQvjkg608V9pu4_AIlI=.6400b97e-90b6-4b31-8e03-a49a8bf51197@github.com>
 <381e0979-ae04-63e5-df58-3cdb96bb8797@oracle.com>
 <BY5PR10MB400244A685D7CC87419F276A87D79@BY5PR10MB4002.namprd10.prod.outlook.com>
 <fcdd9f29-aaa4-84d2-6d8e-7d7b5493aae4@oracle.com>
Message-ID: <BY5PR10MB40028FFB4298E12B60950D9387D69@BY5PR10MB4002.namprd10.prod.outlook.com>

When they return, these methods meet the property, even for -0.0 provided the underlying eq is floating-point ==, not *::compare:
    -0.0 -> 0 -> 0.0
and there is a loss of information about the sign bit.

However, as currently stated, the property is not 100% correct. For example,
    (long) (double) Long.MAX_VALUE == Long.MAX_VALUE
evaluates to true but you cannot conclude that Long.MAX_VALUE is converted exactly to a double: indeed, it is not.
The methods deal with these special cases and throw.
The tests for pattern matching should deal with special cases as well.




From: Brian Goetz <brian.goetz at oracle.com>
Date: Wednesday, 25 May 2022 at 17:18
To: Raffaello Giulietti <raffaello.giulietti at oracle.com>, core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
Another way to evaluate answers here is: are we inventing new relations, or merely clarifying old ones?  The latter is often more desirable.

For example, we might say that x:X can be converted exactly to Y, for primitive X and Y, iff:

    eq( (X) (Y) x, x )

where `eq` is `==` for non-floating primitive types, and derived from Float::compare and Double::compare for floating point.  This means we are not inventing any new conversions or comparisons, but merely combining ones we already have in the language/platform in a convenient way.

Do the toXExact methods you've defined have this characteristic?

(Though, while this is often the best starting place, it is not always a slam-dunk answer; sometimes there are good reasons to depart from existing relations, but we should be explicit about what those are.)


On 5/25/2022 9:46 AM, Raffaello Giulietti wrote:
The motivation behind this PR is not driven by pattern matching: John Rose (the reporter of the JBS issue) is concerned about having safer casts that, in addition, can be JITted to efficient code.

But I get your point that having non-throwing tests better serves pattern matching. However, I?m not sure that pattern matching alone would remove the more general need for the proposed methods.

As for the controversial question about -0.0, as you note any proposal will kind of suck. With ?safer? cast methods we can have two (or even more) variants.

In the context of primitive pattern matching (including the relevant material in the JLS), however, it would be probably much simpler to allow for matches between integral types on one side and for matches between floating-point types on the other side, but not a mix. The nuisance with -0.0 and other special values would disappear altogether.

Thus, while examples like
    if (anIntExpression instanceof byte b)
and
    if (aDoubleExpression instanceof float f)
make perfect sense, would an example like
    if (aDoubleExpression instanceof short s)
be pragmatically reasonable?

IIRC, the discussions about ?Primitive type patterns? and ?Evolving past reference type patterns? in the amber-spec-experts mailing list of April 2022 don?t even mention the mixed integral/floating-point case.


Greetings
Raffaello


From: core-libs-dev <core-libs-dev-retn at openjdk.java.net><mailto:core-libs-dev-retn at openjdk.java.net> on behalf of Brian Goetz <brian.goetz at oracle.com><mailto:brian.goetz at oracle.com>
Date: Tuesday, 24 May 2022 at 00:09
To: Raffaello Giulietti <duke at openjdk.java.net><mailto:duke at openjdk.java.net>, core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net> <core-libs-dev at openjdk.java.net><mailto:core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
This work is quite timely as we are now paving the way for primitive
type patterns over in Project Amber, and also has a nontrivial
connection with Valhalla.  If you'll pardon a brief digression...

Instanceof and casting work together in a familiar way: before you cast,
you first ask instanceof -- but this is restricted currently to
reference types.  But the pattern is obvious: instanceof is the
precondition check for casting, which asks: "If I made this cast, would
I like the answer."  There are currently two reasons to not like the
answer: a CCE, or the operand is null (because, even though the cast
would succeed, if you tried to use it as a member of that type, you
wouldn't like the answer then.)

If we wanted to extend `instanceof` to primitive types, we are asking
the same question: if I were to cast to this type, would I like the
answer.  And casts involving primitives give us two more reasons to not
like the answer: an NPE (due to unboxing), or loss of precision.  Which
means that we have to specify in JLS 5.1 what cast with loss of
precision means.  At the very least, we will want to align this work
with that; the asXExact should be able to say "throws if the cast would
lose precision", where "lose precision" is precisely defined by the JLS.

Separately, Project Valhalla will let us define new primitive-like
types, such as HalfFloat and SuperLong. Conversions between primitives
are currently specified in a complex table in JLS 5.1.  But surely we
will want to support primitive widening conversions between HalfFloat
and float (somehow; how we do this is a separate discussion.)  Which
brings us back to pattern matching; narrowing casts are inherently
partial, and declared patterns bring partiality into the "return type",
and are the natural way (when we have it) to express things like "cast,
but fail if you can't do so safely". This is preferable to throwing
(which currently is the our choice.)  So it might be a little
unfortunate to introduce throwing toXExactly now and then have to
introduce separate patterns which signal precision loss by match
failure.  (Though that's not the end of the world if there is some
duplication.)

What this says is that the current proposal of toXExact is not the
primitive, because we probably wouldn't want to implement a pattern in
terms of the throwing version.

Converting from float/double to integral types is particularly tricky
with -0.0.  Both answers kind of suck.  (This is a familiar situation,
and these can be very difficult to resolve, as for each position,
*someone* has decided the other position is untenable.)  I understand
the rationale behind Michael H's "but its not exact", but let's not
pretend one answer is good and the other sucks -- they both suck, and
therefore the decision can be made on other factors.

So I have a few new wrinkles to add to the story:

  - We should wait until we have candidate JLS text for "cast conversion
without loss of precision", and ensure the two are consistent, before
pushing;
  - I not quite comfortable with settling the -0.0 issue just yet, there
are some other explorations to complete first;
  - We should be prepared for the fact that we will, sometime soon, have
to implement this whole set again as patterns that do not throw.








On 5/5/2022 6:18 AM, Raffaello Giulietti wrote:
> Add a family of "safe" cast methods.
>
> -------------
>
> Commit messages:
>   - 8279986: methods Math::asXExact for safely checked primitive casts
>   - 8279986: methods Math::asXExact for safely checked primitive casts
>   - 8279986: methods Math::asXExact for safely checked primitive casts
>
> Changes:https://git.openjdk.java.net/jdk/pull/8548/files
>   Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=8548&range=00
>    Issue:https://bugs.openjdk.java.net/browse/JDK-8279986
>    Stats: 615 lines in 2 files changed: 609 ins; 0 del; 6 mod
>    Patch:https://git.openjdk.java.net/jdk/pull/8548.diff
>    Fetch: git fetchhttps://git.openjdk.java.net/jdk  pull/8548/head:pull/8548
>
> PR:https://git.openjdk.java.net/jdk/pull/8548


From sgehwolf at openjdk.java.net  Wed May 25 16:14:50 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 25 May 2022 16:14:50 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v3]
In-Reply-To: <vjsUBMDkqQG79SPFt2ft-uTUdI5RhKjc94T3HwX1omA=.7923adc9-f111-4aab-b860-6ccd88019ff0@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
 <vjsUBMDkqQG79SPFt2ft-uTUdI5RhKjc94T3HwX1omA=.7923adc9-f111-4aab-b860-6ccd88019ff0@github.com>
Message-ID: <Jh07tDgF0dxxWQ-peVaNpxPpjCY20QtoMKiqnx9FqjI=.96ec973a-b917-4d2b-92ef-587c59a488dd@github.com>

On Wed, 25 May 2022 15:51:04 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode.
>> 
>> The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1).
>> 
>> However, the "hybrid checks" only considers the following controllers that Java cares about:
>> 
>> - cpu
>> - cpuacct
>> - cpuset
>> - blkio
>> - memory
>> - pids
>> 
>> If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert.
>> 
>> 
>> $ cat /proc/self/cgroup
>> 1:freezer:/
>> 0::/user.slice/user-1001.slice/session-85.scope
>> 
>> 
>> The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed comments

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 149:

> 147:             // other controllers (such as freezer) are ignored and
> 148:             // are not considered in the checks below for
> 149:             // anyCgroupsV1Controller/anyCgroupsV1Controller.

It still has the `anyCgroupsV1Controller/anyCgroupsV1Controller` typo. Not **V1** twice?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From kvn at openjdk.java.net  Wed May 25 16:28:27 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 25 May 2022 16:28:27 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v9]
In-Reply-To: <QGHTZd-YKn_P2rF_qyIoxuysgQzOuw53e21tx6OolKk=.6465c8fc-3464-4ed4-ac32-f37f18004736@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <XOdud1tXGKpB0r0eVOyrQyPRF6I_cnnYHyaTep-sMsA=.f0e9e656-39c9-4505-b21f-bac023c32ccf@github.com>
 <QGHTZd-YKn_P2rF_qyIoxuysgQzOuw53e21tx6OolKk=.6465c8fc-3464-4ed4-ac32-f37f18004736@github.com>
Message-ID: <7J9iS711pZ787GWlBS6vmDen-X_YVULXxkR-cPRuYQs=.467502a6-5dd2-40dd-9393-9d685c24e1a1@github.com>

On Wed, 25 May 2022 06:29:06 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8284960: Review comments resolved.
>
> Hi @vnkozlov , Your comments have been addressed.

@jatin-bhateja something wrong with merge. `vpadd()` is removed. It was added by #8778 and still is used in `x86.ad`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From naoto at openjdk.java.net  Wed May 25 16:50:32 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 25 May 2022 16:50:32 GMT
Subject: RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter
Message-ID: <AuT4206YbwsSuQiao5sCJjPyYj7ITF2DZJr2Ao8PzRc=.1db17f55-0da7-474f-8725-893a0ceee408@github.com>

Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones.

-------------

Commit messages:
 - 8287187: Utilize HashMap.newHashMap() in CLDRConverter

Changes: https://git.openjdk.java.net/jdk/pull/8887/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8887&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287187
  Stats: 65 lines in 1 file changed: 8 ins; 1 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8887/head:pull/8887

PR: https://git.openjdk.java.net/jdk/pull/8887

From raffaello.giulietti at oracle.com  Wed May 25 16:57:11 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 25 May 2022 16:57:11 +0000
Subject: RFR: [CSR] 8287026: Changes related to overflow handling in
 Random.doubles
Message-ID: <BY5PR10MB400264E94D452FC87FC6526887D69@BY5PR10MB4002.namprd10.prod.outlook.com>

Please review this CSR [1], whose aim is to bring the extended behavior of the PR [2] in sync with the spec.

Greetings
Raffaello

----

[1] https://bugs.openjdk.java.net/browse/JDK-8287026
[2] https://git.openjdk.java.net/jdk/pull/8791


From iklam at openjdk.java.net  Wed May 25 17:14:28 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 25 May 2022 17:14:28 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v3]
In-Reply-To: <Y2V_Ztdt9jwb8wN0Q8Xtvg7VFDfzpDVv2RPLRz_uBO4=.25caf9ad-44a0-4a7e-9816-4e90cb58030c@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
 <EisSyVHbjSUIyBsszUjM97_OwD8Jt2cBIzSpXZpAEu8=.c62a5c40-e727-4f27-96d5-c7e5087725f0@github.com>
 <ddUidECANrWtWa9L99eKLekZaltBGZh07WPdZwadEpI=.adb52b74-6624-4b1f-bf7b-a62aef5b9aeb@github.com>
 <pa4qHV9MGgYhWwOnMydw25tUfRFh7ozC-sez1mfPHIE=.126361a3-4b05-47e9-ab1a-f8589d31df2d@github.com>
 <RV2RrYZIThRLap-I9rJS4hitj4OHW5q6iBmABrAaWoE=.76f9fa14-987c-4e94-a94a-671a7e40c391@github.com>
 <f2VI8ODNEnRwjN1oZKd0aGc3UwuwT3yMijcxYLSyetk=.2763038e-74a3-4ab0-8878-9dd42e01e58d@github.com>
 <Y2V_Ztdt9jwb8wN0Q8Xtvg7VFDfzpDVv2RPLRz_uBO4=.25caf9ad-44a0-4a7e-9816-4e90cb58030c@github.com>
Message-ID: <X7fZYvtwlOQUfTJvyH7zhmGoJTxV2mrpSeWgA4jCbB8=.f1de0c62-7f5f-4f1b-af95-a779aacc44d7@github.com>

On Wed, 25 May 2022 15:50:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> It confused me, fwiw. Anyway up to you. It's not super important.
>
> works for me. +1. Note the typo `anyCgroupsV1Controller/anyCgroupsV2Controller` not **V1** twice.

Oops, I'll fixed that. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From naoto at openjdk.java.net  Wed May 25 17:15:18 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 25 May 2022 17:15:18 GMT
Subject: RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter [v2]
In-Reply-To: <AuT4206YbwsSuQiao5sCJjPyYj7ITF2DZJr2Ao8PzRc=.1db17f55-0da7-474f-8725-893a0ceee408@github.com>
References: <AuT4206YbwsSuQiao5sCJjPyYj7ITF2DZJr2Ao8PzRc=.1db17f55-0da7-474f-8725-893a0ceee408@github.com>
Message-ID: <liwuqzOJfgloYQdlSz69VTNJhGmmouRlgjGsDBLtr8I=.653b615e-658a-452a-ab48-49e2c36f1141@github.com>

> Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  minor fixup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8887/files
  - new: https://git.openjdk.java.net/jdk/pull/8887/files/faab3ea1..c2cc3391

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8887&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8887&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8887/head:pull/8887

PR: https://git.openjdk.java.net/jdk/pull/8887

From uschindler at openjdk.java.net  Wed May 25 17:51:14 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 25 May 2022 17:51:14 GMT
Subject: RFR: 8287206: Use WrongThreadException for confinement errors
In-Reply-To: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
References: <3bAzMNon4fLvxdDOEFOhBxdzg4f2IxpmS7lvyWxn2Lc=.08f2b39b-6498-40e6-9018-8d7a26939ecd@github.com>
Message-ID: <qJQ1gi6dtu-UEzgF4DLLGbYZSsIU7DUC2KKVgJbwFac=.94fabac3-f7a2-4a33-9232-55190ba42362@github.com>

On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch tweaks the foreign API to use the newly added `WrongThreadException` instead of `IllegalStateException` to report confinement errors.

I changed the PR on our side, `IllegalStateException` is fine, if you catch it as close as possible to the code calling varhandles and so on (which is the case for Lucene). Thanks for this PR, makes life much easier!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8865

From raffaello.giulietti at oracle.com  Wed May 25 18:11:34 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 25 May 2022 18:11:34 +0000
Subject: RFR: [CSR] 8287026: Changes related to overflow handling in
 Random.doubles
In-Reply-To: <BY5PR10MB400264E94D452FC87FC6526887D69@BY5PR10MB4002.namprd10.prod.outlook.com>
References: <BY5PR10MB400264E94D452FC87FC6526887D69@BY5PR10MB4002.namprd10.prod.outlook.com>
Message-ID: <BY5PR10MB4002B791A47CCCC57B0DA22287D69@BY5PR10MB4002.namprd10.prod.outlook.com>

Sorry, it's the other way round!
To bring the spec in sync with the extended behavior of the PR [2]


From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Raffaello Giulietti <raffaello.giulietti at oracle.com>
Date: Wednesday, 25 May 2022 at 18:57
To: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Subject: RFR: [CSR] 8287026: Changes related to overflow handling in Random.doubles
Please review this CSR [1], whose aim is to bring the extended behavior of the PR [2] in sync with the spec.

Greetings
Raffaello

----

[1] https://bugs.openjdk.java.net/browse/JDK-8287026
[2] https://git.openjdk.java.net/jdk/pull/8791

From rriggs at openjdk.java.net  Wed May 25 19:27:13 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 25 May 2022 19:27:13 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <PimNyakuyuROLm8fW2DtGIZpz-0tIi-V3u4ZFCDARe0=.4375bec8-7a2c-4937-ae88-5be8253b6a8d@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/65e59633...05cf2d8b

AccessFlags.SUPER can/should be removed; it is unused and will be redefined in the [Value Objects JEP](https://openjdk.java.net/jeps/8277163).
It will be a cleaner transition if there is no opportunity to create a dependency on the obsolete flag.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From mchung at openjdk.java.net  Wed May 25 19:47:43 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 25 May 2022 19:47:43 GMT
Subject: RFR: JDK-8281001 Examine the behavior of Class::forName if the
 caller is null [v2]
In-Reply-To: <mZmtII2DwrYj6mcbUZQ3O7X3N0qXYMlyWSDRvX1ncgI=.4e4b6dec-6f71-4f24-9a19-ed047e576b1b@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
 <mZmtII2DwrYj6mcbUZQ3O7X3N0qXYMlyWSDRvX1ncgI=.4e4b6dec-6f71-4f24-9a19-ed047e576b1b@github.com>
Message-ID: <-QlgJ5d07wcHXEycUkP6INUS5cMi5otibEaF_ZJkYX8=.fbb4ae05-6760-4c42-a78d-78b04cb55963@github.com>

On Tue, 17 May 2022 20:16:48 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added javadoc comment

src/java.base/share/classes/java/lang/Class.java line 361:

> 359:      *
> 360:      * <p>
> 361:      * This method is caller sensitive.  In cases where this method is called

You can drop "This method is caller sensitive." sentence for consistency with other caller-sensitive methods that do not state that explicitly.   The javadoc already specifies that it uses the class loader of the current class.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8711

From joehw at openjdk.java.net  Wed May 25 20:47:42 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 25 May 2022 20:47:42 GMT
Subject: RFR: 8287187: Utilize HashMap.newHashMap() in CLDRConverter [v2]
In-Reply-To: <liwuqzOJfgloYQdlSz69VTNJhGmmouRlgjGsDBLtr8I=.653b615e-658a-452a-ab48-49e2c36f1141@github.com>
References: <AuT4206YbwsSuQiao5sCJjPyYj7ITF2DZJr2Ao8PzRc=.1db17f55-0da7-474f-8725-893a0ceee408@github.com>
 <liwuqzOJfgloYQdlSz69VTNJhGmmouRlgjGsDBLtr8I=.653b615e-658a-452a-ab48-49e2c36f1141@github.com>
Message-ID: <WKjEE18j0iBhCflb3h5Tg9aFyz2K5qcd9LzH2Fkylec=.7eb8a4b1-c4c0-4f6d-bd16-624b27ef8504@github.com>

On Wed, 25 May 2022 17:15:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor fixup

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8887

From naoto at openjdk.java.net  Wed May 25 21:27:46 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 25 May 2022 21:27:46 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v10]
In-Reply-To: <ygVOfOf_7rweffzpsQpkhpkD4xmWWMDWzgO77th2jcg=.75ef70a8-fc7b-476d-b7dc-ecfbdea832bf@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
 <ygVOfOf_7rweffzpsQpkhpkD4xmWWMDWzgO77th2jcg=.75ef70a8-fc7b-476d-b7dc-ecfbdea832bf@github.com>
Message-ID: <JOvunu9jzADTaZen541-sXKe2z36VjHp5Z_yGvrT_iY=.2a725372-e262-4275-8d00-93a41bf75f1d@github.com>

On Wed, 25 May 2022 05:42:22 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> (Also, I haven't seen `StringTokenizer` in a long time....)

That's some old code lingering in locale-related stuff. Will fix them after this PR gets integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed May 25 22:05:41 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 25 May 2022 22:05:41 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v10]
In-Reply-To: <stq4JTmCFMDrKktVkCrQw-q-9rpDuM4crfEBv9tJ4yQ=.60e57538-8f98-408a-bd67-45666bc9aee5@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
 <-Lz_SOx7WHvfqv36TSbyZ9yt776HP8lomlb6qTICfyk=.ca9d268e-86eb-4d4e-aec9-aea81ba5ca04@github.com>
 <stq4JTmCFMDrKktVkCrQw-q-9rpDuM4crfEBv9tJ4yQ=.60e57538-8f98-408a-bd67-45666bc9aee5@github.com>
Message-ID: <nMBuZJ7HbnhfIFiFSbewfS8whDHtq7zaWwfI67aIFnQ=.749c4e39-e5bb-48ba-a7aa-48bbd0bf9cd4@github.com>

On Wed, 25 May 2022 05:22:44 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Yes, this test fails with IllegalAccessException. Probably it's easiest to use a VarHandle to get private fields, similar to other usage already in this test.
> 
> This test case is a bit odd though in that it's supposed to test HashSet and LinkedHashSet but it mostly actually tests HashMap. It creates the Set instance and immediately extracts the HashMap, which is then passed to the actual test, which operates directly on the HashMap.

Considering about it being a whitebox test, it is not very weird, but still weird enough.
A better way might be wrap it into another layer.
Will try it when I have time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From bpb at openjdk.java.net  Wed May 25 23:16:21 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 25 May 2022 23:16:21 GMT
Subject: RFR: 8287003: InputStreamReader::read() can return zero despite
 writing a char in the buffer
Message-ID: <DNKgrHEdMCHUZN1X6wk2bcMm9zW_UDdCXWPgoeuVdIU=.b4d7c426-20e1-48e5-a8a1-029b5d74f5ce@github.com>

If only a leftover `char` remains in the stream, do not add `-1` to the return value in `lockedRead()`.

-------------

Commit messages:
 - 8287003: InputStreamReader::read() can return zero despite writing a char in the buffer

Changes: https://git.openjdk.java.net/jdk/pull/8895/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8895&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287003
  Stats: 33 lines in 2 files changed: 24 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8895.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8895/head:pull/8895

PR: https://git.openjdk.java.net/jdk/pull/8895

From skuksenko at openjdk.java.net  Wed May 25 23:26:55 2022
From: skuksenko at openjdk.java.net (Sergey Kuksenko)
Date: Wed, 25 May 2022 23:26:55 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v15]
In-Reply-To: <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
Message-ID: <2upOvyHn5d_AceCQzZhKkoQ0TnGLi_B60ZbsFaT13Sw=.52222cbf-b7fa-47fb-a876-73dfb1bb4f81@github.com>

On Tue, 24 May 2022 20:40:51 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   invert if; refine javadoc.

Is there any practical scenario where the current code (skip buffer allocation on each invocation) creates issues?
Most leaf InputStreams have their own skip implementation. And the same question for Reader class.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From iklam at openjdk.java.net  Wed May 25 23:49:48 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 25 May 2022 23:49:48 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v4]
In-Reply-To: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
Message-ID: <HDE8dkVSNwwNk2ka8I9mtw1R508uAjoq5BwClR_c7xg=.874ae1be-aa7b-406c-b299-8a3317b97b99@github.com>

> This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode.
> 
> The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1).
> 
> However, the "hybrid checks" only considers the following controllers that Java cares about:
> 
> - cpu
> - cpuacct
> - cpuset
> - blkio
> - memory
> - pids
> 
> If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert.
> 
> 
> $ cat /proc/self/cgroup
> 1:freezer:/
> 0::/user.slice/user-1001.slice/session-85.scope
> 
> 
> The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name).

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo in comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8858/files
  - new: https://git.openjdk.java.net/jdk/pull/8858/files/9134182e..a13afe47

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8858&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8858.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8858/head:pull/8858

PR: https://git.openjdk.java.net/jdk/pull/8858

From kbarrett at openjdk.java.net  Thu May 26 04:03:54 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 26 May 2022 04:03:54 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9]
In-Reply-To: <zll-VXYgVeeBoeccn4lFcOrvlpyjO5N61vqnkt5EKeg=.853ed5c9-5d0e-4acc-9e75-079f20b0e542@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <zll-VXYgVeeBoeccn4lFcOrvlpyjO5N61vqnkt5EKeg=.853ed5c9-5d0e-4acc-9e75-079f20b0e542@github.com>
Message-ID: <TnqIGXb10Pou1eSt0VwsU7owwtcAkpxhjpOAtcZruKs=.869f7604-1e26-4765-af09-3311117faea5@github.com>

On Wed, 25 May 2022 09:16:43 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Change Array::data() implementation
>  - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp

Mostly good, but I missed a problem with an earlier part of the change.  Sorry I didn't notice sooner.

src/java.base/unix/native/libjli/java_md_common.c line 133:

> 131: 
> 132:     snprintf_result = JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd);
> 133:     if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) {

That should be `||` rather than `&&`.

src/java.base/unix/native/libjli/java_md_common.c line 135:

> 133:     if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) {
> 134:       return 0;
> 135:     }

Pre-existing: It seems odd that this returns `0` above and below, rather than returning `NULL`.  I think there are one or two other places in this file that are similarly using literal `0` for a null pointer, though others are using `NULL`.  Something to report and clean up separately from this change.

-------------

Changes requested by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8646

From iklam at openjdk.java.net  Thu May 26 04:19:47 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 26 May 2022 04:19:47 GMT
Subject: RFR: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with
 freezer controller [v2]
In-Reply-To: <IcangTrRCuXa6VismUsCp6apXbvj64hriam6fZT5WlA=.befddda8-5cb8-4390-b42e-d13ce376b572@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
 <Ep6v5vDnXI4JIaR1xNn-Fmdj_l_-4WFkBLPqlArY9eI=.e9babec6-3e1a-4152-88b6-4a8fdbe83fa9@github.com>
 <IcangTrRCuXa6VismUsCp6apXbvj64hriam6fZT5WlA=.befddda8-5cb8-4390-b42e-d13ce376b572@github.com>
Message-ID: <psKZPWqlt4kKdixGcGWUZkbUfojRd9WP9KPBvQymXw0=.f9e994fa-b6ec-4f61-b7d0-65945b8ecf1b@github.com>

On Tue, 24 May 2022 19:36:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @jerboaa comments
>
> Looks good. Thanks for the thorough analysis.

Thanks @jerboaa and @mseledts for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From iklam at openjdk.java.net  Thu May 26 04:19:49 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 26 May 2022 04:19:49 GMT
Subject: Integrated: 8287107: CgroupSubsystemFactory.setCgroupV2Path asserts
 with freezer controller
In-Reply-To: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
References: <A7jAIf294ByruLsmJt_dORfzYAkyN6edSgQk7Apl_hc=.fcc163ae-9e87-4429-963d-2892521abc49@github.com>
Message-ID: <i7oMLzql3VRfHeWMKDw2DXeQ5nTzM2kN7CY-OV_PW9I=.e034548e-eb05-4d6b-8b48-06508f25b880@github.com>

On Mon, 23 May 2022 22:11:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This PR fixes a bug found on an Ubuntu host that's mostly running with cgroupv2, but there's a controller (freezer) that is mounted in cgroupv1 mode.
> 
> The container support code in the VM and JDK checks if we have simultaneously mounted v1 and v2 containers. If so, we revert to "hybrid" mode (which is essentially v1).
> 
> However, the "hybrid checks" only considers the following controllers that Java cares about:
> 
> - cpu
> - cpuacct
> - cpuset
> - blkio
> - memory
> - pids
> 
> If only "freezer" is mounted in v1 mode, Java will start in V2 mode. Later, when `setCgroupV2Path()` sees the first line in /proc/self/cgroup, it runs into the assert.
> 
> 
> $ cat /proc/self/cgroup
> 1:freezer:/
> 0::/user.slice/user-1001.slice/session-85.scope
> 
> 
> The fix is simple -- when we get to `setCgroupV2Path()`, we have already decided that the system has not mounted any v1 controllers that we care about, so we should just ignore all the v1 controllers (which has a non-empty name).

This pull request has now been integrated.

Changeset: 704b9a66
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/704b9a66bba0dc8adb62be80fd62864b9c687c3f
Stats:     117 lines in 3 files changed: 114 ins; 0 del; 3 mod

8287107: CgroupSubsystemFactory.setCgroupV2Path asserts with freezer controller

Reviewed-by: mseledtsov, sgehwolf

-------------

PR: https://git.openjdk.java.net/jdk/pull/8858

From jbhateja at openjdk.java.net  Thu May 26 06:22:09 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 26 May 2022 06:22:09 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v8]
In-Reply-To: <4u_PL8-QxIYVBgJ23LTdoPWZrTKh70K-beMYXOXZgQQ=.a650a280-dc75-46cd-8449-00c38ddd91ea@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
 <MIC5Sq_7Vvy7XAkLQ-HFQ0ydRv8XPHuBQhR53eSLQN0=.3b396db1-43fd-4348-b89c-ff8377281c91@github.com>
 <4u_PL8-QxIYVBgJ23LTdoPWZrTKh70K-beMYXOXZgQQ=.a650a280-dc75-46cd-8449-00c38ddd91ea@github.com>
Message-ID: <y5Ta4jB0djcr542yMTNSHzQHhxEWo41A_BmGuR25SoU=.5b5564ec-005f-424f-89d0-afc4a49df680@github.com>

On Wed, 25 May 2022 06:25:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/assembler_x86.cpp line 8173:
>> 
>>> 8171: 
>>> 8172: void Assembler::vinsertf32x4(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) {
>>> 8173:   assert(VM_Version::supports_evex(), "");
>> 
>> Hmm, did we never trigger this wrong assert because the use was guarded by correct check?
>
> Yes.

> @jatin-bhateja something wrong with merge. `vpadd()` is removed. It was added by #8778 and still is used in `x86.ad`.

Hi @vnkozlov , after integration of PR 8778 there were there were two copies of vpadd with same signature, so removed one of them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From plevart at openjdk.java.net  Thu May 26 06:31:27 2022
From: plevart at openjdk.java.net (Peter Levart)
Date: Thu, 26 May 2022 06:31:27 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance()
In-Reply-To: <6_iySZ7wuU98uaAd2Pw3DqFn7cCr4ex8r3zb-vX7N4o=.0485c0d1-6d68-4da9-939e-6d7a494adaad@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
 <_6tzEtf0vVpRlzeVthCLiLuVCoK2EhgKxbHe8WU-TV4=.ae1222b5-20af-4634-9412-c17d6d161bd3@github.com>
 <zEp9jO73YLvh-Hc0JHNaOgj-HUXCVVegCu-ug9wwr1w=.7c897d26-7a10-41fd-b1dd-bd1a04b3ad1d@github.com>
 <6_iySZ7wuU98uaAd2Pw3DqFn7cCr4ex8r3zb-vX7N4o=.0485c0d1-6d68-4da9-939e-6d7a494adaad@github.com>
Message-ID: <DNZNNoiqYagFEVG2lwupzUVOeZ8SLzXSMV1AX4Uf6Xw=.8401c912-404a-4db7-a70f-ff5e89d59a67@github.com>

On Wed, 25 May 2022 15:54:04 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> `CgroupV1Subsystem.getInstance(...)` also claims that it never returns `null`, but has a code-path that actually returns `null` (when there is no active controller). Is this a possible outcome?
>
> @plevart Are you asking about the reason for the crash or about the changes?
> If it's the former, then I believe that the crash comes not from `getInstance()` returning `null`, but from further down the stack because `null` is being passed to `getInstance()`. I could be wrong in interpreting the report, though.
> 
> If the question's about the changes, then those are restricted to CgroupV2, so I'm not sure how `CgroupV1Subsystem.getInstance(...)` returning null is related. FWIW, I also don't think we are going to get here if there are no active controllers. There's this code a few lines above:
> 
> if (!result.isAnyControllersEnabled()) {
>             return null;
> }

I was just contemplating the code around the change as it appears to have unnecessary checks which result in dead code. From the point of fixing just this concrete NPE, they are irrelevant. So while this code might benefit from cleanup, perhaps this PR is not the place to do it. Perhaps it is a matter of another issue and PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From jpai at openjdk.java.net  Thu May 26 07:31:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 26 May 2022 07:31:46 GMT
Subject: RFR: 8287285: Avoid redundant HashMap.containsKey call in
 java.util.zip.ZipFile.Source.get
In-Reply-To: <ZupMHluCLPM_cAsoG4beDZ_z3-aRel-v7M_2w3OVPi4=.29a36738-15d5-42ca-bb20-a38b2f4b22d1@github.com>
References: <ZupMHluCLPM_cAsoG4beDZ_z3-aRel-v7M_2w3OVPi4=.29a36738-15d5-42ca-bb20-a38b2f4b22d1@github.com>
Message-ID: <UeSWPK7rHoapYRoMEBbw1pTkdNir9qXb-g8G-AL5Er8=.4372533c-bd19-47e0-95fc-77ab61489c90@github.com>

On Sat, 30 Apr 2022 08:56:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> The method `java.util.zip.ZipFile.Source#get` could be improved by usage of `Map.putIfAbsent` instead of separate `containsKey`/`get`/`put` calls. We known that HashMap `java.util.zip.ZipFile.Source#files` can contain only non-null values. And to check if putIfAbsent was successful or not we can just compare result with `null`.
> It makes code a bit cleaner and faster.

The change looks fine to me. Please wait for at least one more review from someone having more knowledge of this area, before merging.

-------------

Marked as reviewed by jpai (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8481

From duke at openjdk.java.net  Thu May 26 07:32:54 2022
From: duke at openjdk.java.net (duke)
Date: Thu, 26 May 2022 07:32:54 GMT
Subject: Withdrawn: JDK-8277095 : Empty streams create too many objects
In-Reply-To: <YOPQ14TqFLOfPSNmXkVOwGQuPCgDssYeVQoIOULKnSU=.1e46116c-6c49-43e8-b30a-273a06226b8c@github.com>
References: <YOPQ14TqFLOfPSNmXkVOwGQuPCgDssYeVQoIOULKnSU=.1e46116c-6c49-43e8-b30a-273a06226b8c@github.com>
Message-ID: <1P9lTlppz3KRk9Q6lFHQveVoojiI77osq67likJ3bnA=.cb81008d-be24-42c7-9cd9-f17d76e43221@github.com>

On Fri, 5 Nov 2021 12:53:46 GMT, kabutz <duke at openjdk.java.net> wrote:

> This is a draft proposal for how we could improve stream performance for the case where the streams are empty. Empty collections are common-place. If we iterate over them with an Iterator, we would have to create one small Iterator object (which could often be eliminated) and if it is empty we are done. However, with Streams we first have to build up the entire pipeline, until we realize that there is no work to do. With this example, we change Collection#stream() to first check if the collection is empty, and if it is, we simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and EmptyDoubleStream. We have taken great care for these to have the same characteristics and behaviour as the streams returned by Stream.empty(), IntStream.empty(), etc. 
> 
> Some of the JDK tests fail with this, due to ClassCastExceptions (our EmptyStream is not an AbstractPipeline) and AssertionError, since we can call some methods repeatedly on the stream without it failing. On the plus side, creating a complex stream on an empty stream gives us upwards of 50x increase in performance due to a much smaller object allocation rate. This PR includes the code for the change, unit tests and also a JMH benchmark to demonstrate the improvement.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6275

From alanb at openjdk.java.net  Thu May 26 08:31:24 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 26 May 2022 08:31:24 GMT
Subject: RFR: 8287285: Avoid redundant HashMap.containsKey call in
 java.util.zip.ZipFile.Source.get
In-Reply-To: <ZupMHluCLPM_cAsoG4beDZ_z3-aRel-v7M_2w3OVPi4=.29a36738-15d5-42ca-bb20-a38b2f4b22d1@github.com>
References: <ZupMHluCLPM_cAsoG4beDZ_z3-aRel-v7M_2w3OVPi4=.29a36738-15d5-42ca-bb20-a38b2f4b22d1@github.com>
Message-ID: <fo3xEHsRpnmqYKumpQlPc91frz9QvSS6bqV7x23VYeM=.68a38009-a3bd-41c9-8031-fb8cb29103c5@github.com>

On Sat, 30 Apr 2022 08:56:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> The method `java.util.zip.ZipFile.Source#get` could be improved by usage of `Map.putIfAbsent` instead of separate `containsKey`/`get`/`put` calls. We known that HashMap `java.util.zip.ZipFile.Source#files` can contain only non-null values. And to check if putIfAbsent was successful or not we can just compare result with `null`.
> It makes code a bit cleaner and faster.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8481

From mcimadamore at openjdk.java.net  Thu May 26 08:38:43 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 26 May 2022 08:38:43 GMT
Subject: Integrated: 8287244: Add bound check in indexed memory access var
 handle
In-Reply-To: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
References: <lCsu_u5_SB9T6osXYAOnHuhXKBlvBuUYptZsOizD0rE=.e0765d7f-b777-4086-97fa-b174d9df24c9@github.com>
Message-ID: <Ye5PeJq9dMh0jgVh4BHU7IOFTGXSMXIU4p_ohqwsWu8=.f473496b-dcb2-4969-afb4-4de9c57411af@github.com>

On Tue, 24 May 2022 14:40:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Constructing indexed var handles using the `MemoryLayout` API produces `VarHandle` which do not check the input indices for out-of-bounds conditions.
> While this can never result in a VM crash (after all the memory segment will protect against "true" OOB access), it is still possible for an access expression to refer to parts of a segment that are logically unrelated.
> 
> This patch adds a "logical" bound check to all indexed var handles generated using the layout API.
> Benchmarks are not affected by the check. Users are still able to create custom "unchecked" var handles, using the combinator API in `MethodHandles`.

This pull request has now been integrated.

Changeset: f58c9a65
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f58c9a659ba181407ecdb2aacb81e6a7f1cbd9ff
Stats:     92 lines in 4 files changed: 70 ins; 5 del; 17 mod

8287244: Add bound check in indexed memory access var handle

Reviewed-by: psandoz, jvernee

-------------

PR: https://git.openjdk.java.net/jdk/pull/8868

From mkartashev at openjdk.java.net  Thu May 26 09:42:22 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 26 May 2022 09:42:22 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance() [v2]
In-Reply-To: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
Message-ID: <CvJk6Wc4tSuIfe1bOpHszR5cukXVFHd-S3GIvwKLjU0=.696ed0dd-d6be-479f-a593-f7bce8cb248e@github.com>

> Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. 
> 
> It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  Removed unnecessary null checks

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8803/files
  - new: https://git.openjdk.java.net/jdk/pull/8803/files/f17af433..932ff6d1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8803&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8803&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8803/head:pull/8803

PR: https://git.openjdk.java.net/jdk/pull/8803

From mkartashev at openjdk.java.net  Thu May 26 09:42:22 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 26 May 2022 09:42:22 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance() [v2]
In-Reply-To: <DNZNNoiqYagFEVG2lwupzUVOeZ8SLzXSMV1AX4Uf6Xw=.8401c912-404a-4db7-a70f-ff5e89d59a67@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
 <_6tzEtf0vVpRlzeVthCLiLuVCoK2EhgKxbHe8WU-TV4=.ae1222b5-20af-4634-9412-c17d6d161bd3@github.com>
 <zEp9jO73YLvh-Hc0JHNaOgj-HUXCVVegCu-ug9wwr1w=.7c897d26-7a10-41fd-b1dd-bd1a04b3ad1d@github.com>
 <6_iySZ7wuU98uaAd2Pw3DqFn7cCr4ex8r3zb-vX7N4o=.0485c0d1-6d68-4da9-939e-6d7a494adaad@github.com>
 <DNZNNoiqYagFEVG2lwupzUVOeZ8SLzXSMV1AX4Uf6Xw=.8401c912-404a-4db7-a70f-ff5e89d59a67@github.com>
Message-ID: <D2lTnGSBnkP9QIUrDB5DcV3awhWGuRzyscADpmhZHuw=.8dd0187c-9fa2-456a-b14b-cb52389371ab@github.com>

On Thu, 26 May 2022 06:28:22 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> @plevart Are you asking about the reason for the crash or about the changes?
>> If it's the former, then I believe that the crash comes not from `getInstance()` returning `null`, but from further down the stack because `null` is being passed to `getInstance()`. I could be wrong in interpreting the report, though.
>> 
>> If the question's about the changes, then those are restricted to CgroupV2, so I'm not sure how `CgroupV1Subsystem.getInstance(...)` returning null is related. FWIW, I also don't think we are going to get here if there are no active controllers. There's this code a few lines above:
>> 
>> if (!result.isAnyControllersEnabled()) {
>>             return null;
>> }
>
> I was just contemplating the code around the change as it appears to have unnecessary checks which result in dead code. From the point of fixing just this concrete NPE, they are irrelevant. So while this code might benefit from cleanup, perhaps this PR is not the place to do it. Perhaps it is a matter of another issue and PR.

@plevart I think I now understand what you meant and removed the unnecessary checks. Please, have a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From ysuenaga at openjdk.java.net  Thu May 26 10:55:28 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 26 May 2022 10:55:28 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v10]
In-Reply-To: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
Message-ID: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com>

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
> 
> * -Wstringop-overflow
>     * src/hotspot/share/oops/array.hpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
> 
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8646/files
  - new: https://git.openjdk.java.net/jdk/pull/8646/files/17cda224..851279ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=08-09

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8646.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646

PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Thu May 26 10:55:29 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 26 May 2022 10:55:29 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9]
In-Reply-To: <TnqIGXb10Pou1eSt0VwsU7owwtcAkpxhjpOAtcZruKs=.869f7604-1e26-4765-af09-3311117faea5@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <zll-VXYgVeeBoeccn4lFcOrvlpyjO5N61vqnkt5EKeg=.853ed5c9-5d0e-4acc-9e75-079f20b0e542@github.com>
 <TnqIGXb10Pou1eSt0VwsU7owwtcAkpxhjpOAtcZruKs=.869f7604-1e26-4765-af09-3311117faea5@github.com>
Message-ID: <4B8Ib70PFV8uvUPrVUSiLk5560QAhHhUkJFpyyzUmRk=.c1f7b721-e51a-4e24-b8b3-a896bff7e1b4@github.com>

On Thu, 26 May 2022 03:48:31 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Change Array::data() implementation
>>  - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp
>
> src/java.base/unix/native/libjli/java_md_common.c line 133:
> 
>> 131: 
>> 132:     snprintf_result = JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd);
>> 133:     if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) {
> 
> That should be `||` rather than `&&`.

Good catch! I fixed it in new commit.

> src/java.base/unix/native/libjli/java_md_common.c line 135:
> 
>> 133:     if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) {
>> 134:       return 0;
>> 135:     }
> 
> Pre-existing: It seems odd that this returns `0` above and below, rather than returning `NULL`.  I think there are one or two other places in this file that are similarly using literal `0` for a null pointer, though others are using `NULL`.  Something to report and clean up separately from this change.

I was wondering about that too.
I use `NULL` at L134, and have filed it as [JDK-8287363](https://bugs.openjdk.java.net/browse/JDK-8287363). I will work for it after this issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From iklam at openjdk.java.net  Thu May 26 15:29:42 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 26 May 2022 15:29:42 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance() [v2]
In-Reply-To: <CvJk6Wc4tSuIfe1bOpHszR5cukXVFHd-S3GIvwKLjU0=.696ed0dd-d6be-479f-a593-f7bce8cb248e@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
 <CvJk6Wc4tSuIfe1bOpHszR5cukXVFHd-S3GIvwKLjU0=.696ed0dd-d6be-479f-a593-f7bce8cb248e@github.com>
Message-ID: <aJk0MqHe2fU1H0ebfKQI-VOORoCXf6E2OryOhr9ADmw=.137bb469-a6ba-4775-a35a-974dffe7b2c6@github.com>

On Thu, 26 May 2022 09:42:22 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. 
>> 
>> It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary null checks

Changes requested by iklam (Reviewer).

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 113:

> 111:             CgroupInfo anyController = infos.values().iterator().next();
> 112:             CgroupSubsystem subsystem = CgroupV2Subsystem.getInstance(anyController);
> 113:             return new CgroupMetrics(subsystem);

Should add `Objects.requireNonNull(anyController)` and `Objects.requireNonNull(subsystem)`.

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 116:

> 114:         } else {
> 115:             CgroupV1Subsystem subsystem = CgroupV1Subsystem.getInstance(infos);
> 116:             return new CgroupV1MetricsImpl(subsystem);

This shouldn't be changed because the current implementation of `CgroupV1Subsystem.getInstance(infos)` has a path that returns null.

Maybe that's impossible, because when we call `CgroupV1Subsystem.getInstance`, we must have at least one v1 subsystem in `infos`. However, that's not related to this issue.  Please fix that in a separate RFE. For example, `CgroupV1Subsystem.getInstance(infos)`  can be changed to throw an exception instead if return null.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From duke at openjdk.java.net  Thu May 26 15:47:52 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 26 May 2022 15:47:52 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v15]
In-Reply-To: <2upOvyHn5d_AceCQzZhKkoQ0TnGLi_B60ZbsFaT13Sw=.52222cbf-b7fa-47fb-a876-73dfb1bb4f81@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
 <2upOvyHn5d_AceCQzZhKkoQ0TnGLi_B60ZbsFaT13Sw=.52222cbf-b7fa-47fb-a876-73dfb1bb4f81@github.com>
Message-ID: <u1LwXpHdXo-gTNdxmPgr5sSznS_pvHTY7FKX709TrEc=.9bb13c80-9015-49be-bf55-b8b461385049@github.com>

On Wed, 25 May 2022 23:23:13 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> Is there any practical scenario where the current code (skip buffer allocation on each invocation) creates issues?

@kuksenko Not found any yet :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From naoto at openjdk.java.net  Thu May 26 15:55:41 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 26 May 2022 15:55:41 GMT
Subject: Integrated: 8287187: Utilize HashMap.newHashMap() in CLDRConverter
In-Reply-To: <AuT4206YbwsSuQiao5sCJjPyYj7ITF2DZJr2Ao8PzRc=.1db17f55-0da7-474f-8725-893a0ceee408@github.com>
References: <AuT4206YbwsSuQiao5sCJjPyYj7ITF2DZJr2Ao8PzRc=.1db17f55-0da7-474f-8725-893a0ceee408@github.com>
Message-ID: <UmuG9vFTOYs5kx6HflC4eIbaEHkYZSE_1eKYsdbLHIk=.71711199-defb-43ce-88f8-1b1ed956acd0@github.com>

On Wed, 25 May 2022 16:43:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones.

This pull request has now been integrated.

Changeset: c10749a6
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c10749a6a70977fbd6cd33b298410d212276fcf1
Stats:     65 lines in 1 file changed: 8 ins; 1 del; 56 mod

8287187: Utilize HashMap.newHashMap() in CLDRConverter

Reviewed-by: joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/8887

From mkartashev at openjdk.java.net  Thu May 26 16:04:17 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 26 May 2022 16:04:17 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance() [v3]
In-Reply-To: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
Message-ID: <9hRC8HIFXnO9nVT7BXFnNBo_ZM5nAvIgxreAgQU0p1Q=.de49b0e4-9107-4ae7-84f7-2a805c19ad68@github.com>

> Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. 
> 
> It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map.

Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:

  Made requested changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8803/files
  - new: https://git.openjdk.java.net/jdk/pull/8803/files/932ff6d1..9e6c0f37

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8803&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8803&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8803.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8803/head:pull/8803

PR: https://git.openjdk.java.net/jdk/pull/8803

From mkartashev at openjdk.java.net  Thu May 26 16:04:18 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 26 May 2022 16:04:18 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance() [v2]
In-Reply-To: <aJk0MqHe2fU1H0ebfKQI-VOORoCXf6E2OryOhr9ADmw=.137bb469-a6ba-4775-a35a-974dffe7b2c6@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
 <CvJk6Wc4tSuIfe1bOpHszR5cukXVFHd-S3GIvwKLjU0=.696ed0dd-d6be-479f-a593-f7bce8cb248e@github.com>
 <aJk0MqHe2fU1H0ebfKQI-VOORoCXf6E2OryOhr9ADmw=.137bb469-a6ba-4775-a35a-974dffe7b2c6@github.com>
Message-ID: <_U8zggXJhq0WZuGhPRFvCb8YJplXu0GeLZ_XOp3Xwzk=.f00a1874-1ed3-4857-917d-63ee2b7a0a08@github.com>

On Thu, 26 May 2022 15:23:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unnecessary null checks
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 116:
> 
>> 114:         } else {
>> 115:             CgroupV1Subsystem subsystem = CgroupV1Subsystem.getInstance(infos);
>> 116:             return new CgroupV1MetricsImpl(subsystem);
> 
> This shouldn't be changed because the current implementation of `CgroupV1Subsystem.getInstance(infos)` has a path that returns null.
> 
> Maybe that's impossible, because when we call `CgroupV1Subsystem.getInstance`, we must have at least one v1 subsystem in `infos`. However, that's not related to this issue.  Please fix that in a separate RFE. For example, `CgroupV1Subsystem.getInstance(infos)`  can be changed to throw an exception instead if return null.

Fine by me; done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From mkartashev at openjdk.java.net  Thu May 26 16:06:16 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Thu, 26 May 2022 16:06:16 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance() [v2]
In-Reply-To: <aJk0MqHe2fU1H0ebfKQI-VOORoCXf6E2OryOhr9ADmw=.137bb469-a6ba-4775-a35a-974dffe7b2c6@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
 <CvJk6Wc4tSuIfe1bOpHszR5cukXVFHd-S3GIvwKLjU0=.696ed0dd-d6be-479f-a593-f7bce8cb248e@github.com>
 <aJk0MqHe2fU1H0ebfKQI-VOORoCXf6E2OryOhr9ADmw=.137bb469-a6ba-4775-a35a-974dffe7b2c6@github.com>
Message-ID: <1M_YlIz3X-LW2DNJTm7l5W_18yDWn-ThIv_X4f36tfM=.62f1973e-57ae-4289-a2fb-c5022ae57b00@github.com>

On Thu, 26 May 2022 15:25:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unnecessary null checks
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 113:
> 
>> 111:             CgroupInfo anyController = infos.values().iterator().next();
>> 112:             CgroupSubsystem subsystem = CgroupV2Subsystem.getInstance(anyController);
>> 113:             return new CgroupMetrics(subsystem);
> 
> Should add `Objects.requireNonNull(anyController)` and `Objects.requireNonNull(subsystem)`.

I added the first, but not the second as that looks like an overkill; see the definition of the constructor:

    CgroupMetrics(CgroupSubsystem subsystem) {
        this.subsystem = Objects.requireNonNull(subsystem);
    }

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From duke at openjdk.java.net  Thu May 26 17:42:16 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 26 May 2022 17:42:16 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v11]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <JP9F762ArE_p3uhdvpcJgcX1DxRfQX52Cdt_IvQJw1s=.be26278f-5aae-4131-a348-7ac6efcd9def@github.com>

> as title.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  rename items to elements

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/56d029f4..4ec6ba9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=09-10

  Stats: 12 lines in 2 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Thu May 26 17:42:17 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 26 May 2022 17:42:17 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v10]
In-Reply-To: <ygVOfOf_7rweffzpsQpkhpkD4xmWWMDWzgO77th2jcg=.75ef70a8-fc7b-476d-b7dc-ecfbdea832bf@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
 <ygVOfOf_7rweffzpsQpkhpkD4xmWWMDWzgO77th2jcg=.75ef70a8-fc7b-476d-b7dc-ecfbdea832bf@github.com>
Message-ID: <RKs6qThMr_30sBH5GjSUrGgZVbnekZuZ9HzA0vj3QJw=.8c1a7838-cb2f-44c7-8633-a203563d794e@github.com>

On Wed, 25 May 2022 05:07:12 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test for newHashSet and newLinkedHashSet
>
> src/java.base/share/classes/java/util/HashSet.java line 398:
> 
>> 396:     public static <E> HashSet<E> newHashSet(int numItems) {
>> 397:         return new HashSet<>(HashMap.calculateHashMapCapacity(numItems));
>> 398:     }
> 
> Please use "elements" instead of "items" throughout the specifications for the objects that are members of the HashSet. This includes the API notes above as well as the specs and API notes in LinkedHashSet.

@stuart-marks done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Thu May 26 17:54:20 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Thu, 26 May 2022 17:54:20 GMT
Subject: RFR: JDK-8281001 Examine the behavior of Class::forName if the
 caller is null [v3]
In-Reply-To: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
References: <XWR4al13u1r6oCkaMlJVBtr-nZgVevFsfR1wPIiGpLs=.da97329b-4e22-4389-86a4-7619b6590cf3@github.com>
Message-ID: <AvRvTaypbbA3UruelcmTQodauiWp_3_PK60YI1RUqxM=.6a0d810b-7503-4459-8e90-a10bf7d89e76@github.com>

> The Class::forName behavior change to match JNI FindClass is a compatible change and seems pretty attractive as it would be expected that Class::forName would give the same behavior as FindClass which uses the system classloader.  The test for 8281006 was enhanced to test for this change.  Merged master to pick up fixes to unrelated test failures to reduce noise.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  make javadoc consistent with other caller sensitve methods

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8711/files
  - new: https://git.openjdk.java.net/jdk/pull/8711/files/9d054ea6..4e5f8c2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8711&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8711&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8711/head:pull/8711

PR: https://git.openjdk.java.net/jdk/pull/8711

From duke at openjdk.java.net  Thu May 26 18:04:58 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 26 May 2022 18:04:58 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v10]
In-Reply-To: <eed5Bgj0PTL0VXr_xpLzuasG5I7EY_E6UtE7Blcn1O4=.bca7531c-c170-4de7-9ebf-be7440f5848c@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
 <eed5Bgj0PTL0VXr_xpLzuasG5I7EY_E6UtE7Blcn1O4=.bca7531c-c170-4de7-9ebf-be7440f5848c@github.com>
Message-ID: <4TLm7TA6ESzqd661FJwMf0nwp3FSCDPt1t5si1Rsa70=.05f1a82f-88b9-406a-86bd-33c7e8a2cc57@github.com>

On Wed, 25 May 2022 04:50:33 GMT, liach <duke at openjdk.java.net> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add test for newHashSet and newLinkedHashSet
>
> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 354:
> 
>> 352:                 rsc("rsls", size, cap, () -> {
>> 353:                     try {
>> 354:                         Field mapField = HashSet.class.getDeclaredField("map");
> 
> For clarity, consider using var handle/method handle and keep the reflection code in the `WhiteBoxResizeTest` constructor.

@liach I refactored the tests. please have a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Thu May 26 18:04:55 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 26 May 2022 18:04:55 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v12]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <0m4CpBRFJtRMu2BuG3MkWgy010kwrhgqNDO46THiY6o=.aabcf1f7-f41c-47bd-97f8-eea8dad54be5@github.com>

> as title.

XenoAmess has updated the pull request incrementally with two additional commits since the last revision:

 - add 8284780 to test
 - redo the tests

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/4ec6ba9f..df5a8512

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=10-11

  Stats: 92 lines in 1 file changed: 65 ins; 16 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Thu May 26 18:05:00 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 26 May 2022 18:05:00 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v10]
In-Reply-To: <stq4JTmCFMDrKktVkCrQw-q-9rpDuM4crfEBv9tJ4yQ=.60e57538-8f98-408a-bd67-45666bc9aee5@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <aH_VKTjE95yjNxj2s_8HQoMv_0ND-Tr70BBy2ILY8pM=.42c215c9-437e-41e1-9d6d-0be6a3005baf@github.com>
 <-Lz_SOx7WHvfqv36TSbyZ9yt776HP8lomlb6qTICfyk=.ca9d268e-86eb-4d4e-aec9-aea81ba5ca04@github.com>
 <stq4JTmCFMDrKktVkCrQw-q-9rpDuM4crfEBv9tJ4yQ=.60e57538-8f98-408a-bd67-45666bc9aee5@github.com>
Message-ID: <P-pS11IpPI4tDP79v2uQsIlmTUow4s8JfMGGinrOjxU=.ff914ed3-cbf8-49e3-8417-e9280a117c48@github.com>

On Wed, 25 May 2022 05:22:44 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 360:
>> 
>>> 358:                         throw new RuntimeException(e);
>>> 359:                     }
>>> 360:                 })
>> 
>> These?probably?need a?`mapField.setAccessible(true)`?call, or?a?`VarHandle` for?the?`HashSet.map`?field.
>
> Yes, this test fails with IllegalAccessException. Probably it's easiest to use a VarHandle to get private fields, similar to other usage already in this test.
> 
> This test case is a bit odd though in that it's supposed to test HashSet and LinkedHashSet but it mostly actually tests HashMap. It creates the Set instance and immediately extracts the HashMap, which is then passed to the actual test, which operates directly on the HashMap. It would be preferable to create a Set; add an element (so that it's properly allocated); and then make assertions over the Set (which involve extracting the HashMap, etc.) It seems like there should be factoring that allows this sort of arrangement to be retrofitted without adding too much complication.
> 
> Finally, please add "8284780" to the `@bug` line at the top of this test.

@stuart-marks I refactored the tests. please have a look.

@stuart-marks 8284780 added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Thu May 26 18:06:39 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 26 May 2022 18:06:39 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v13]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <dVgtAYz-S6t1n-Mi3tNIEJqvQUvHgDDdRBD-exKT598=.d94a02b5-5c55-4b28-a16a-cefe76981398@github.com>

> as title.

XenoAmess has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge remote-tracking branch 'openjdk/master' into fix_8284780
   
   # Conflicts:
   #	test/jdk/java/util/HashMap/WhiteBoxResizeTest.java
 - add 8284780 to test
 - redo the tests
 - rename items to elements
 - add test for newHashSet and newLinkedHashSet
 - revert much too changes for newHashSet
 - add more replaces
 - add more replaces
 - add more replaces
 - add more replaces
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/7eb15593...59caa1f4

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8302/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=12
  Stats: 162 lines in 31 files changed: 120 ins; 0 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Thu May 26 18:08:13 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 26 May 2022 18:08:13 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v14]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <vmYk6F4vkRB2HmpWMmGGHGb1r8W5btmkULpY0mxQGAQ=.0d068364-e67a-4f05-9194-f0044ce52496@github.com>

> as title.

XenoAmess has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into fix_8284780
 - Merge remote-tracking branch 'openjdk/master' into fix_8284780
   
   # Conflicts:
   #	test/jdk/java/util/HashMap/WhiteBoxResizeTest.java
 - add 8284780 to test
 - redo the tests
 - rename items to elements
 - add test for newHashSet and newLinkedHashSet
 - revert much too changes for newHashSet
 - add more replaces
 - add more replaces
 - add more replaces
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7cb368b3...117918f4

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8302/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=13
  Stats: 162 lines in 31 files changed: 120 ins; 0 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Thu May 26 18:10:11 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 26 May 2022 18:10:11 GMT
Subject: RFR: 8233760: Result of BigDecimal.toString throws overflow exception
 on new BigDecimal(str)
Message-ID: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>

BigDecimal(String) currently fails to accept some strings produced by BigDecimal.toString(). This PR removes this limitation.

-------------

Commit messages:
 - 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str)

Changes: https://git.openjdk.java.net/jdk/pull/8905/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8905&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8233760
  Stats: 48 lines in 2 files changed: 2 ins; 26 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8905.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8905/head:pull/8905

PR: https://git.openjdk.java.net/jdk/pull/8905

From duke at openjdk.java.net  Thu May 26 18:10:11 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Thu, 26 May 2022 18:10:11 GMT
Subject: RFR: 8233760: Result of BigDecimal.toString throws overflow
 exception on new BigDecimal(str)
In-Reply-To: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
References: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
Message-ID: <YITb_HcgdDa_QSObkiJJFnvPVVLBidlrjkZ6b_3Y3Qc=.ba11aefc-90db-48e3-8cee-abd7602cdab9@github.com>

On Thu, 26 May 2022 18:02:14 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> BigDecimal(String) currently fails to accept some strings produced by BigDecimal.toString(). This PR removes this limitation.

This happens because the constructor currently only accepts exponents in the `int` range (more precisely, in the open range (-2^31, 2^31)).
It should accept a larger range of exponents, as long as the resulting `BigDecimal` has a scale in the `int` range.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8905

From kbarrett at openjdk.java.net  Thu May 26 18:18:41 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 26 May 2022 18:18:41 GMT
Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v10]
In-Reply-To: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com>
Message-ID: <Bu7AHYbga39Rr-WKSy5F-gLsudab-Bkxde6CXEFlQOA=.c34a314a-fbb5-4878-aaaa-a7cd9749c610@github.com>

On Thu, 26 May 2022 10:55:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>> 
>> * -Wstringop-overflow
>>     * src/hotspot/share/oops/array.hpp
>>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>> 
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Marked as reviewed by kbarrett (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From iklam at openjdk.java.net  Thu May 26 18:20:42 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 26 May 2022 18:20:42 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance() [v3]
In-Reply-To: <9hRC8HIFXnO9nVT7BXFnNBo_ZM5nAvIgxreAgQU0p1Q=.de49b0e4-9107-4ae7-84f7-2a805c19ad68@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
 <9hRC8HIFXnO9nVT7BXFnNBo_ZM5nAvIgxreAgQU0p1Q=.de49b0e4-9107-4ae7-84f7-2a805c19ad68@github.com>
Message-ID: <l8yU6a-DphwRA7B4v8Up9vZmNJXsOfojtXLk9lMkxbY=.32d31e78-793b-4acf-b02a-e4d934da2c14@github.com>

On Thu, 26 May 2022 16:04:17 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. 
>> 
>> It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made requested changes

Marked as reviewed by iklam (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From duke at openjdk.java.net  Thu May 26 18:24:38 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 26 May 2022 18:24:38 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v4]
In-Reply-To: <xMAQ0rG1GEFkU-ct6ub6Ezln8hoHnn2jHkmGWZ3J3bQ=.16aecdda-aa21-48a0-9f91-044a604651dd@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <dG50e4tph85P83R-ErBDznD1MCRHJ981upFennWzxTc=.afb7c439-9284-4396-94b1-8a9c6aac5d2e@github.com>
 <4I-FrEU8zBFD0-4pDPYZ948aQvIXHicUyTpbiUqKTj8=.377d95a6-af67-44be-8443-c4af58f8b95e@github.com>
 <9PqOY0Ho6mgINFO8ya5NeaZZB3RaATgWx7LJ-ESRSds=.37fdca9a-7af5-4ba5-8c85-baf9d33013ac@github.com>
 <xMAQ0rG1GEFkU-ct6ub6Ezln8hoHnn2jHkmGWZ3J3bQ=.16aecdda-aa21-48a0-9f91-044a604651dd@github.com>
Message-ID: <0wu4q9q4FMy-z0qqMVAy-0wCADxTK4goL1Qoy-XIdrU=.5c3c7e68-fc70-4a15-b062-f96548091595@github.com>

On Wed, 18 May 2022 23:20:45 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> Need to add apiNote documentation section to capacity-based constructors like for maps.
>> 
>> @liach done.
>
> @XenoAmess oops, sorry for the delay. I think it would be good to get these into 19 as companions to `HashMap.newHashMap` et. al.
> 
> As before, I'd suggest reducing the number of changes to use sites in order to make review easier. I would suggest keeping the changes under src in java.base, java.net.http, java.rmi, and jdk.zipfs, and omitting all the other changes. Also keep the changes under test/jdk.
> 
> There needs to be a test for these new methods. I haven't thought much how to do that. My first attempt would be to modify our favorite WhiteBoxResizeTest and add a bit of machinery that asserts the table length of the HashMap contained within the created HashSet/LinkedHashSet. I haven't looked at it though, so it might not work out, in which case you should pursue an alternative approach.
> 
> I'll look at the specs and suggest updates as necessary and then handle filing of a CSR.

@stuart-marks @liach 
Hi guys.
After a good sleep and a rethink, I re-wrote some part of the test.
It seems be logically better than the way before.
please have a look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From mchung at openjdk.java.net  Thu May 26 18:48:34 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 26 May 2022 18:48:34 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v4]
In-Reply-To: <RtOpX4OMD3kepUTXjP_WkfsaG--PafeQiZArJR48dyE=.96fca2e4-e46a-45b8-af9b-c72bd233d873@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <RtOpX4OMD3kepUTXjP_WkfsaG--PafeQiZArJR48dyE=.96fca2e4-e46a-45b8-af9b-c72bd233d873@github.com>
Message-ID: <Q1duSNN2_DHsk5h52CSGOKYuoP-DaQr_V_Lkv1cxItw=.897096b3-958c-4112-a086-790916faf5df@github.com>

On Fri, 20 May 2022 02:25:32 GMT, liach <duke at openjdk.java.net> wrote:

>> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
>> 
>> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update

src/java.base/share/classes/java/lang/reflect/Proxy.java line 514:

> 512:                 // Per JLS 7.4.2, unnamed package can only exist in unnamed modules.
> 513:                 // This means a package-private superinterface exist in the unnamed
> 514:                 // package of a named module.

With this patch, I think line 505-517 can turn into assert or internal error as you suggested.   Probably can be moved to the `ProxyClassContext` constructor too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From xuelei at openjdk.java.net  Thu May 26 18:58:13 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 26 May 2022 18:58:13 GMT
Subject: RFR: 8287384: Speed up ForceGC
Message-ID: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>

Hi,

May I have this test update reviewed?

The ForceGC could be enhanced by using smaller wait/sleep time, and shared cleaner.

Thanks,
Xuelei

-------------

Commit messages:
 - 8287384: Speed up ForceGC

Changes: https://git.openjdk.java.net/jdk/pull/8907/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8907&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287384
  Stats: 21 lines in 1 file changed: 8 ins; 1 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8907/head:pull/8907

PR: https://git.openjdk.java.net/jdk/pull/8907

From iklam at openjdk.java.net  Thu May 26 19:29:40 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 26 May 2022 19:29:40 GMT
Subject: RFR: 8287384: Speed up ForceGC
In-Reply-To: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
Message-ID: <gTGQO3XYjCzUloPlmR1iCwptZQW7vxWHQDFrcHZ1Ppg=.1b82b75d-e8bb-4d2f-82be-06ed21f5ff85@github.com>

On Thu, 26 May 2022 18:50:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this test update reviewed?
> 
> The ForceGC could be enhanced by using smaller wait/sleep time, and shared cleaner.
> 
> Thanks,
> Xuelei

Please rename the RFE title to be less generic. How about "Speed up jdk.test.lib.util.ForceGC"?

-------------

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8907

From duke at openjdk.java.net  Thu May 26 20:06:17 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 26 May 2022 20:06:17 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v6]
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <PhD65zj3w0iben21c3Daxb7hZYvsHrc875f2C6Y0HlA=.d7f4c209-2ab2-41ee-b9ec-c46a85e97672@github.com>

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - 8282662: Revert wrong copyright year change
 - 8282662: Revert ProxyGenerator
 - 8282662: Revert ProxyGenerator
 - 8282662: Revert dubious changes in MethodType
 - 8282662: Revert dubious changes
 - 8282662: Use List/Set.of() factory methods to save memory

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7729/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=05
  Stats: 12 lines in 4 files changed: 1 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7729.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729

PR: https://git.openjdk.java.net/jdk/pull/7729

From aturbanov at openjdk.java.net  Thu May 26 20:36:40 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 26 May 2022 20:36:40 GMT
Subject: Integrated: 8287285: Avoid redundant HashMap.containsKey call in
 java.util.zip.ZipFile.Source.get
In-Reply-To: <ZupMHluCLPM_cAsoG4beDZ_z3-aRel-v7M_2w3OVPi4=.29a36738-15d5-42ca-bb20-a38b2f4b22d1@github.com>
References: <ZupMHluCLPM_cAsoG4beDZ_z3-aRel-v7M_2w3OVPi4=.29a36738-15d5-42ca-bb20-a38b2f4b22d1@github.com>
Message-ID: <Br_S2pZklvY44lsHZtzPB_ZjPgEAYGR5zofNCJuYGJU=.391ff2b1-88d5-4832-877c-fc89d23a3986@github.com>

On Sat, 30 Apr 2022 08:56:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> The method `java.util.zip.ZipFile.Source#get` could be improved by usage of `Map.putIfAbsent` instead of separate `containsKey`/`get`/`put` calls. We known that HashMap `java.util.zip.ZipFile.Source#files` can contain only non-null values. And to check if putIfAbsent was successful or not we can just compare result with `null`.
> It makes code a bit cleaner and faster.

This pull request has now been integrated.

Changeset: 295be6f1
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/295be6f10ff50eb743c6840e7dcd319fe6f39d0f
Stats:     6 lines in 1 file changed: 0 ins; 1 del; 5 mod

8287285: Avoid redundant HashMap.containsKey call in java.util.zip.ZipFile.Source.get

Reviewed-by: jpai, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8481

From duke at openjdk.java.net  Thu May 26 20:52:43 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 26 May 2022 20:52:43 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v4]
In-Reply-To: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
Message-ID: <RbL7fWso4C5Ua4rPTOtsCzO4wq2mAO1JYeqXaNH7xs0=.abcbd42d-60ed-4be0-a5ca-8faee8533d05@github.com>

> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of `Class.forName(String)`. `make test TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new `LazyInitializationTest` failing the eager initialization check on the baseline and passing with this patch.
> 
> On a side note, this might reduce the number of methods that can be encoded in a proxy due to code attribute size restrictions; we probably would address that in another issue, as we never mandated a count of methods that the proxy must be able to implement.
> 
> Mandy, would you mind review this?

liach 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 eight additional commits since the last revision:

 - Merge branch 'master' into proxy-class-forname
 - Move the try catch block as it doesn't throw checked exceptions
 - remove unused field
 - whitespace
 - Copyright year
 - typo
 - 8285401: Proxy class initializer should use 3-arg `Class.forName` to avoid unnecessary class initialization
 - Test for eager initialization

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8800/files
  - new: https://git.openjdk.java.net/jdk/pull/8800/files/82f8eeb9..1262e8fa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8800&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8800&range=02-03

  Stats: 37306 lines in 626 files changed: 8637 ins; 27109 del; 1560 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8800.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8800/head:pull/8800

PR: https://git.openjdk.java.net/jdk/pull/8800

From duke at openjdk.java.net  Thu May 26 20:53:29 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 26 May 2022 20:53:29 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v5]
In-Reply-To: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
Message-ID: <RA5sgigVATuc7_Et30DNS8dJZjot7hadEgzon0jl8ew=.079510a5-8bc8-49bb-8105-51ca942e833b@github.com>

> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
> 
> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.

liach 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 seven additional commits since the last revision:

 - Group proxy location validation all into the class context constructor
 - Merge branch 'master' into fix/proxy-single-pass
 - Update
 - Updates suggested by mandy
 - Merge branch 'master' into fix/proxy-single-pass
 - Don't need to complexify module cache
 - 8284942: Proxy building can just iterate superinterfaces once

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8281/files
  - new: https://git.openjdk.java.net/jdk/pull/8281/files/26bde80b..20edc525

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=03-04

  Stats: 37340 lines in 627 files changed: 8639 ins; 27112 del; 1589 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8281/head:pull/8281

PR: https://git.openjdk.java.net/jdk/pull/8281

From duke at openjdk.java.net  Thu May 26 20:55:53 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 26 May 2022 20:55:53 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v3]
In-Reply-To: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
Message-ID: <X_hAi-_31Lxf4hcgul5brgGVxRd64HdjUZFdmkciTqQ=.0e84f6a1-bd55-4efc-8062-2b1ee119fd2d@github.com>

> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)

liach 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 proxy-primitivetypeinfo
 - Convert PrimitiveTypeInfo to an enum
 - 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8801/files
  - new: https://git.openjdk.java.net/jdk/pull/8801/files/be9987bb..96c0835e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8801&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8801&range=01-02

  Stats: 37306 lines in 626 files changed: 8637 ins; 27109 del; 1560 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8801.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8801/head:pull/8801

PR: https://git.openjdk.java.net/jdk/pull/8801

From kvn at openjdk.java.net  Thu May 26 21:04:14 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 26 May 2022 21:04:14 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v10]
In-Reply-To: <VHAcCWLYeUyK0upiw42TqjQ_FvoSrzj2bLEFbvkZCF8=.165b6038-072b-4d77-a070-461604c782c7@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <VHAcCWLYeUyK0upiw42TqjQ_FvoSrzj2bLEFbvkZCF8=.165b6038-072b-4d77-a070-461604c782c7@github.com>
Message-ID: <i92cv4lHJoLjTt9s-KYGx5e0itmBIQNzM0yjP1VnkTI=.1174fbdc-4bd0-4e0f-922c-53918b0d446c@github.com>

On Wed, 25 May 2022 06:29:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - 8284960: Post merge cleanups.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Review comments resolved.
>  - 8284960: Integrating incremental patches.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms.
>  - 8284960: Adding --enable-preview in vectorAPI benchmarks.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Review comments resolution.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/742644e2...0f6e1584

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8425

From kvn at openjdk.java.net  Thu May 26 21:04:15 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 26 May 2022 21:04:15 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v8]
In-Reply-To: <y5Ta4jB0djcr542yMTNSHzQHhxEWo41A_BmGuR25SoU=.5b5564ec-005f-424f-89d0-afc4a49df680@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com>
 <MIC5Sq_7Vvy7XAkLQ-HFQ0ydRv8XPHuBQhR53eSLQN0=.3b396db1-43fd-4348-b89c-ff8377281c91@github.com>
 <4u_PL8-QxIYVBgJ23LTdoPWZrTKh70K-beMYXOXZgQQ=.a650a280-dc75-46cd-8449-00c38ddd91ea@github.com>
 <y5Ta4jB0djcr542yMTNSHzQHhxEWo41A_BmGuR25SoU=.5b5564ec-005f-424f-89d0-afc4a49df680@github.com>
Message-ID: <lmERHgald5KFWk-RAUdMz41b9OIoUHQ4cpqNHgmepb4=.5148d7f1-dcc7-413a-9206-05821d70214b@github.com>

On Thu, 26 May 2022 06:19:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yes.
>
>> @jatin-bhateja something wrong with merge. `vpadd()` is removed. It was added by #8778 and still is used in `x86.ad`.
> 
> Hi @vnkozlov , after integration of PR 8778 there were there were two copies of vpadd with same signature, so removed one of them.

Okay. Got it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From raffaello.giulietti at oracle.com  Thu May 26 21:16:24 2022
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Thu, 26 May 2022 23:16:24 +0200
Subject: RFR: [CSR] 8287376: BigDecimal(String) must allow a larger range for
 the exponent
Message-ID: <d50e973a-fb94-5d21-1d5b-d94b0d25b652@oracle.com>

Currently, BigDecimal(String) requires the exponent part to lie in the 
int range.

This CSR [1] removes this limitation, as it otherwise precludes 
constructing an instance from a string generated by BigDecimal.toString().


Greetings
Raffaello

----

[1] https://bugs.openjdk.java.net/browse/JDK-8287376

From mchung at openjdk.java.net  Thu May 26 21:21:50 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 26 May 2022 21:21:50 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently [v3]
In-Reply-To: <N7FLxaPZtjFR0h5_KeYIhsWswnopoSuX06Ir-Ba8GyY=.691d4e2c-2840-40f1-82cc-fe9487bcd1a8@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
 <N7FLxaPZtjFR0h5_KeYIhsWswnopoSuX06Ir-Ba8GyY=.691d4e2c-2840-40f1-82cc-fe9487bcd1a8@github.com>
Message-ID: <pdTjqtAeGitseWcNrAJhNd-QMLGHNIhGbyprdco-4mw=.fdc68c5f-9a3b-4242-bc4f-bc784ad0fdfa@github.com>

On Wed, 25 May 2022 14:13:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
>> 
>> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
>> 
>> Baseline:
>> 
>> Benchmark                                                      Mode  Cnt     Score     Error   Units
>> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
>> 
>> 
>> Patched:
>> 
>> Benchmark                                                      Mode  Cnt     Score     Error   Units
>> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed correctly taking b1 into account in of(byte, int, int...) (java/lang/String/concat/ImplicitStringConcatShapes.java test failure)

LGTM with a couple of suggestions.

src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 219:

> 217:             return new TransformKey(fullBytes);
> 218:         }
> 219:         static TransformKey of(byte kind, int b1, int b2, int[] b3456) {

Nit: I can't figure out if `b3456` intends to be a different convention than the others `b123` and `b234`.  I would expect something like this:

Suggestion:

        static TransformKey of(byte kind, int b1, int b2, int... b345) {

src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 252:

> 250:             if (!inRange(bitset))
> 251:                 return 0;
> 252:             pb = pb | b2 << (2 * PACKED_BYTE_SIZE) | b1 << PACKED_BYTE_SIZE | b0;

Suggestion:

            pb = pb | packagedBytes(b0, b1, b2);

src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 267:

> 265:             if (!inRange(bitset))
> 266:                 return 0;
> 267:             pb = pb | b1 << PACKED_BYTE_SIZE | b0;

Suggestion:

            pb = pb | packagedBytes(b0, b1);

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8881

From rriggs at openjdk.java.net  Thu May 26 21:25:40 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 26 May 2022 21:25:40 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
Message-ID: <npvq80nMqrkEtqt8_hRwpH1rVhbaJShmnHWgvtcB7ts=.400df4e0-99c2-4663-b71a-e2fcf5db0e74@github.com>

On Thu, 26 May 2022 18:50:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this test update reviewed?
> 
> The ForceGC could be enhanced by using smaller wait/sleep time, and shared cleaner.
> 
> Thanks,
> Xuelei

Even using a Cleaner is a more overhead than necessary.
I would have skipped the overhead of a cleaner and Atomic classes with something more self contained as a static method:


   /**
     * The garbage collector is invoked to find unreferenced objects.
     * A new object is created and then freed. The method returns
     * when the object has been reclaimed or the GC did not complete in 10 seconds.
     *
     * @return true if GC was complete, false if did not complete after 10 Seconds
     */
    public static boolean waitForGC() {
        ReferenceQueue<Object> queue = new ReferenceQueue<>();
        Object obj = new Object();
        PhantomReference<Object> ref = new PhantomReference<>(obj, queue);
        obj = null;
        Reference.reachabilityFence(obj);
        Reference.reachabilityFence(ref);
        System.gc();

        for (int retries = 100; retries > 0; retries--) {
            try {
                var r = queue.remove(100L);
                if (r != null) {
                    return true;
                }
            } catch (InterruptedException ie) {
                // ignore, the loop will try again
            }
            System.gc();
        }
        return false;
    }

YMMV

-------------

PR: https://git.openjdk.java.net/jdk/pull/8907

From mchung at openjdk.java.net  Thu May 26 21:38:46 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 26 May 2022 21:38:46 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v5]
In-Reply-To: <RA5sgigVATuc7_Et30DNS8dJZjot7hadEgzon0jl8ew=.079510a5-8bc8-49bb-8105-51ca942e833b@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <RA5sgigVATuc7_Et30DNS8dJZjot7hadEgzon0jl8ew=.079510a5-8bc8-49bb-8105-51ca942e833b@github.com>
Message-ID: <-wa607VaVrTIMKT959-L87gmz96R0t6LqWbO7dW8oKo=.3ed40d93-b517-417f-9603-0c184e3dcdbf@github.com>

On Thu, 26 May 2022 20:53:29 GMT, liach <duke at openjdk.java.net> wrote:

>> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
>> 
>> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.
>
> liach 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 seven additional commits since the last revision:
> 
>  - Group proxy location validation all into the class context constructor
>  - Merge branch 'master' into fix/proxy-single-pass
>  - Update
>  - Updates suggested by mandy
>  - Merge branch 'master' into fix/proxy-single-pass
>  - Don't need to complexify module cache
>  - 8284942: Proxy building can just iterate superinterfaces once

src/java.base/share/classes/java/lang/reflect/Proxy.java line 498:

> 496:             new ClassLoaderValue<>();
> 497: 
> 498:         private record ProxyClassContext(Module module, String pkg, int accessFlags) {

Suggestion:

        private record ProxyClassContext(Module module, String packageName, int accessFlags) {

src/java.base/share/classes/java/lang/reflect/Proxy.java line 499:

> 497: 
> 498:         private record ProxyClassContext(Module module, String pkg, int accessFlags) {
> 499:             private ProxyClassContext {

We should validate the `accessFlags` value as it must be 0 or `PUBLIC`.

src/java.base/share/classes/java/lang/reflect/Proxy.java line 513:

> 511: 
> 512:                     if (!module.isOpen(pkg, Proxy.class.getModule())) {
> 513:                         // Required for default method invocation

Is this comment true? 

The module of the proxy class opens the package to `java.base` if the proxy interface is non-public in a named module or if all proxy interfaces are public but a proxy interface is not unconditionally exported.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From xuelei at openjdk.java.net  Thu May 26 21:44:34 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 26 May 2022 21:44:34 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <npvq80nMqrkEtqt8_hRwpH1rVhbaJShmnHWgvtcB7ts=.400df4e0-99c2-4663-b71a-e2fcf5db0e74@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
 <npvq80nMqrkEtqt8_hRwpH1rVhbaJShmnHWgvtcB7ts=.400df4e0-99c2-4663-b71a-e2fcf5db0e74@github.com>
Message-ID: <mndJqriwXrVX13QgdOWq9OsSjJiGdwAJCfLUhL-U7_E=.afda7b54-610c-4dfe-b9c2-087f30087343@github.com>

On Thu, 26 May 2022 21:22:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Even using a Cleaner is a more overhead than necessary. I would have skipped the overhead of a cleaner and Atomic classes with something more self contained as a static method:

I agreed that  the using of Cleaner is still heavy, but it may be acceptable as the code is for testing only.   If a new static method is introduced, test cases using the current API would also need update so as to benefit from it.  I was hesitate for test cases update as it may involve more evaluations (and risks).  But let me check.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8907

From duke at openjdk.java.net  Thu May 26 22:07:35 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 26 May 2022 22:07:35 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v5]
In-Reply-To: <-wa607VaVrTIMKT959-L87gmz96R0t6LqWbO7dW8oKo=.3ed40d93-b517-417f-9603-0c184e3dcdbf@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <RA5sgigVATuc7_Et30DNS8dJZjot7hadEgzon0jl8ew=.079510a5-8bc8-49bb-8105-51ca942e833b@github.com>
 <-wa607VaVrTIMKT959-L87gmz96R0t6LqWbO7dW8oKo=.3ed40d93-b517-417f-9603-0c184e3dcdbf@github.com>
Message-ID: <5MDBe2EG0rhZZKEacioqcPuYCfWXM-Rdkiab4HHK8O8=.c85bc0cd-a05b-41d7-b5e0-b2b788fa9b77@github.com>

On Thu, 26 May 2022 21:32:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> liach 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 seven additional commits since the last revision:
>> 
>>  - Group proxy location validation all into the class context constructor
>>  - Merge branch 'master' into fix/proxy-single-pass
>>  - Update
>>  - Updates suggested by mandy
>>  - Merge branch 'master' into fix/proxy-single-pass
>>  - Don't need to complexify module cache
>>  - 8284942: Proxy building can just iterate superinterfaces once
>
> src/java.base/share/classes/java/lang/reflect/Proxy.java line 513:
> 
>> 511: 
>> 512:                     if (!module.isOpen(pkg, Proxy.class.getModule())) {
>> 513:                         // Required for default method invocation
> 
> Is this comment true? 
> 
> The module of the proxy class opens the package to `java.base` if the proxy interface is non-public in a named module or if all proxy interfaces are public but a proxy interface is not unconditionally exported.

The original check and `Modules.addOpen` calls were added in [8159476](https://bugs.openjdk.java.net/browse/JDK-8159746), when the `invokeDefault` support was added.

See: https://github.com/openjdk/jdk/commit/56b15fbbcc7c04252f2712d859ff7b820b7c79ad#diff-c15cc774a95bac204c294b9ca8e20332c81904e506e16bb7d5a82d1c30cced17R667, or #313

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From rriggs at openjdk.java.net  Thu May 26 22:30:32 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 26 May 2022 22:30:32 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
Message-ID: <_mqzLFmNWFgpqpI2eukP-BhXoYEzrmPWmzHjgywXtX8=.8babbf40-dbd2-4a95-a4b6-6ce5d96d121b@github.com>

On Thu, 26 May 2022 18:50:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this test update reviewed?
> 
> The ForceGC could be enhanced by using smaller wait/sleep time, and shared cleaner.
> 
> Thanks,
> Xuelei

ok, the updates look fine.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8907

From darcy at openjdk.java.net  Thu May 26 22:37:15 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 May 2022 22:37:15 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20
Message-ID: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>

Time to start getting ready for JDK 20...

-------------

Commit messages:
 - Update symbol information for JDK 19 b24.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Update symbol information for JDK 19 b23.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/295be6f1...49c871d9

Changes: https://git.openjdk.java.net/jdk/pull/8236/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284858
  Stats: 6210 lines in 67 files changed: 6166 ins; 0 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

PR: https://git.openjdk.java.net/jdk/pull/8236

From darcy at openjdk.java.net  Thu May 26 22:37:15 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 May 2022 22:37:15 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <B29A3l_xOQdMh3jmtxcJ-hez1n7osjYQg4IQ-1joXSM=.3c8daafa-0a65-45f6-817a-527bf4709dfb@github.com>

On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start getting ready for JDK 20...

The expected kinds of updates to start up JDK 20.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From mchung at openjdk.java.net  Thu May 26 22:37:47 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 26 May 2022 22:37:47 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v5]
In-Reply-To: <5MDBe2EG0rhZZKEacioqcPuYCfWXM-Rdkiab4HHK8O8=.c85bc0cd-a05b-41d7-b5e0-b2b788fa9b77@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <RA5sgigVATuc7_Et30DNS8dJZjot7hadEgzon0jl8ew=.079510a5-8bc8-49bb-8105-51ca942e833b@github.com>
 <-wa607VaVrTIMKT959-L87gmz96R0t6LqWbO7dW8oKo=.3ed40d93-b517-417f-9603-0c184e3dcdbf@github.com>
 <5MDBe2EG0rhZZKEacioqcPuYCfWXM-Rdkiab4HHK8O8=.c85bc0cd-a05b-41d7-b5e0-b2b788fa9b77@github.com>
Message-ID: <-cK9cZaWT49vGfgLRmzTD8S-JEOQ3aCYwNpxp0VuOpA=.9f45f03c-566d-46d4-81cd-75ebf5ffa002@github.com>

On Thu, 26 May 2022 22:01:56 GMT, liach <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/reflect/Proxy.java line 513:
>> 
>>> 511: 
>>> 512:                     if (!module.isOpen(pkg, Proxy.class.getModule())) {
>>> 513:                         // Required for default method invocation
>> 
>> Is this comment true? 
>> 
>> The module of the proxy class opens the package to `java.base` if the proxy interface is non-public in a named module or if all proxy interfaces are public but a proxy interface is not unconditionally exported.
>
> The original check and `Modules.addOpen` calls were added in [8159476](https://bugs.openjdk.java.net/browse/JDK-8159746), when the `invokeDefault` support was added.
> 
> See: https://github.com/openjdk/jdk/commit/56b15fbbcc7c04252f2712d859ff7b820b7c79ad#diff-c15cc774a95bac204c294b9ca8e20332c81904e506e16bb7d5a82d1c30cced17R667, or #313

Ah, I see. That assert was added in PR #313 as a clarification to the current proxy implementation but not required by the `InvocationHandle::invokeDefault`.   It could have been added before the default method support.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From duke at openjdk.java.net  Thu May 26 22:41:33 2022
From: duke at openjdk.java.net (duke)
Date: Thu, 26 May 2022 22:41:33 GMT
Subject: Withdrawn: 8283726: x86 intrinsics for compare method in Integer and
 Long
In-Reply-To: <uewYtLXwRIfkU4FTDAkf2hQBlHOBD4gUNTw8MPUJYHI=.be4845fc-b685-40b5-9d3c-ace72635babf@github.com>
References: <uewYtLXwRIfkU4FTDAkf2hQBlHOBD4gUNTw8MPUJYHI=.be4845fc-b685-40b5-9d3c-ace72635babf@github.com>
Message-ID: <onVtdpRgCB8mhJInkbiJ1dfD03yk0bHm-fQhQV3qnc0=.7509f08b-add2-48c9-ae58-5fa20bb03244@github.com>

On Sun, 27 Mar 2022 06:15:34 GMT, Srinivas Vamsi Parasa <duke at openjdk.java.net> wrote:

> Implements x86 intrinsics for compare() method in java.lang.Integer and java.lang.Long.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7975

From dholmes at openjdk.java.net  Thu May 26 22:46:42 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 26 May 2022 22:46:42 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <OWBo909uodHc7ZOhNe_BK4q0yHcYgEUIluO1__gmDRw=.279398bf-e824-4d9d-8d0d-128285f97926@github.com>

On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start getting ready for JDK 20...

One comment below.
I ignored the sym files.
Everything else appears okay.
Thanks.

src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line 312:

> 310:     int V18 = 0 << 16 | 62;
> 311:     int V19 = 0 << 16 | 63;
> 312:     int V20 = 0 << 17 | 64;

17 ??

Though why do we even bother with this when the minor version is zero? Simple assignment works.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8236

From kcr at openjdk.java.net  Thu May 26 22:46:44 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 26 May 2022 22:46:44 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <jCvgOE5wGiuXGPTLvxmTuC2BCg-YdrXE8zx_zbivCyo=.61b8078b-3fe3-41de-ad15-8d893e1e4878@github.com>

On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to start getting ready for JDK 20...

You also need to change the JBS version from 19 to 20 in [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4):

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From mchung at openjdk.java.net  Thu May 26 22:58:50 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 26 May 2022 22:58:50 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v3]
In-Reply-To: <X_hAi-_31Lxf4hcgul5brgGVxRd64HdjUZFdmkciTqQ=.0e84f6a1-bd55-4efc-8062-2b1ee119fd2d@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <X_hAi-_31Lxf4hcgul5brgGVxRd64HdjUZFdmkciTqQ=.0e84f6a1-bd55-4efc-8062-2b1ee119fd2d@github.com>
Message-ID: <yODApM86n4J-SOvOi9O8o5bcERwZPKMSbAoL_u9kec4=.ecbd5d35-d1f0-43d8-bd4d-5c3a472b1b33@github.com>

On Thu, 26 May 2022 20:55:53 GMT, liach <duke at openjdk.java.net> wrote:

>> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)
>
> liach 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 proxy-primitivetypeinfo
>  - Convert PrimitiveTypeInfo to an enum
>  - 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo

Have you considered including the opcode for load and return instruction instead of `opcodeOffset`?

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 969:

> 967:             // single-char BaseType descriptor (see JVMS section 4.3.2)
> 968:             String baseTypeString = wrapper.basicTypeString();
> 969:             wrapperClassName = dotToSlash(wrapper.wrapperType().getName());

Suggestion:

            wrapperClassName = wrapper.wrapperType().descriptorString();


It may worth to replace similar use of `dotToSlash(c.getName())` pattern.

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 986:

> 984:             if (cl == float.class)   return FLOAT;
> 985:             if (cl == double.class)  return DOUBLE;
> 986:             throw new AssertionError();

Suggestion:

            throw new AssertionError(cl);

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From darcy at openjdk.java.net  Thu May 26 23:05:32 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 May 2022 23:05:32 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>

> Time to start getting ready for JDK 20...

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Respond to review feedback.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/49c871d9..96be1787

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

PR: https://git.openjdk.java.net/jdk/pull/8236

From darcy at openjdk.java.net  Thu May 26 23:05:33 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 May 2022 23:05:33 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20
In-Reply-To: <jCvgOE5wGiuXGPTLvxmTuC2BCg-YdrXE8zx_zbivCyo=.61b8078b-3fe3-41de-ad15-8d893e1e4878@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <jCvgOE5wGiuXGPTLvxmTuC2BCg-YdrXE8zx_zbivCyo=.61b8078b-3fe3-41de-ad15-8d893e1e4878@github.com>
Message-ID: <kUSWYSs_79_tOb5n1wCsTJFciuQ_9Rykv1xw-OdE2K8=.543bb3ac-c033-4701-8190-e59a8b13d6f3@github.com>

On Thu, 26 May 2022 22:40:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> You also need to change the JBS version from 19 to 20 in [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4):

Acknowledged; will fix in the next push. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From darcy at openjdk.java.net  Thu May 26 23:05:33 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 May 2022 23:05:33 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <OWBo909uodHc7ZOhNe_BK4q0yHcYgEUIluO1__gmDRw=.279398bf-e824-4d9d-8d0d-128285f97926@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <OWBo909uodHc7ZOhNe_BK4q0yHcYgEUIluO1__gmDRw=.279398bf-e824-4d9d-8d0d-128285f97926@github.com>
Message-ID: <Mwf6jz76P6Bv1EcfvQaz4V5vdXUhvWOe9rxBNMhp_cU=.ca3c9888-391f-4bf2-9410-196aabb2614c@github.com>

On Thu, 26 May 2022 22:38:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line 312:
> 
>> 310:     int V18 = 0 << 16 | 62;
>> 311:     int V19 = 0 << 16 | 63;
>> 312:     int V20 = 0 << 17 | 64;
> 
> 17 ??
> 
> Though why do we even bother with this when the minor version is zero? Simple assignment works.

Doh! Will fix in the next pushed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From duke at openjdk.java.net  Thu May 26 23:05:49 2022
From: duke at openjdk.java.net (duke)
Date: Thu, 26 May 2022 23:05:49 GMT
Subject: Withdrawn: JDK-8282798 java.lang.runtime.Carrier
In-Reply-To: <FfVJmqeWp_C5JP3jVODWKhgK3a_7HSWZN8DO3XtAlZ0=.20fe7475-517c-42f6-93b2-88e09fe7e0a0@github.com>
References: <FfVJmqeWp_C5JP3jVODWKhgK3a_7HSWZN8DO3XtAlZ0=.20fe7475-517c-42f6-93b2-88e09fe7e0a0@github.com>
Message-ID: <pj0lgsVzeMmgPuviVcwfv3VuuQnrNQLK7Oo0gjaqwnw=.5cd89e15-9b57-45b7-a52d-8df22c1c675c@github.com>

On Tue, 8 Mar 2022 14:02:39 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. 
> 
> See JBS for details.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7744

From duke at openjdk.java.net  Thu May 26 23:10:58 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 26 May 2022 23:10:58 GMT
Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v19]
In-Reply-To: <KgNH-NIRCmMBm6LU-Df2rG-Ck-dSV-kJWcxX8O4rILI=.47473832-e9ed-4090-812a-620410ada763@github.com>
References: <FfVJmqeWp_C5JP3jVODWKhgK3a_7HSWZN8DO3XtAlZ0=.20fe7475-517c-42f6-93b2-88e09fe7e0a0@github.com>
 <KgNH-NIRCmMBm6LU-Df2rG-Ck-dSV-kJWcxX8O4rILI=.47473832-e9ed-4090-812a-620410ada763@github.com>
Message-ID: <3MHFCZrAl6LaFE87mim2__gi9B1ot9xUmut9e-BcQoM=.6682700b-f4e5-427a-aa93-d30d2b396585@github.com>

On Thu, 31 Mar 2022 18:48:39 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. 
>> 
>> See JBS for details.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change Carriers API

Will this be potentially revived if there's any progress in templated strings?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7744

From duke at openjdk.java.net  Thu May 26 23:20:27 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 26 May 2022 23:20:27 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v6]
In-Reply-To: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
Message-ID: <qdr4XR_9GE7BC8eklkGUMN35XhC0ZOxfAyFLY44eCb4=.d5b30f63-1770-4e10-9764-bc786b2e258b@github.com>

> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
> 
> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.

liach has updated the pull request incrementally with one additional commit since the last revision:

  Fixes suggested by mandy

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8281/files
  - new: https://git.openjdk.java.net/jdk/pull/8281/files/20edc525..9d7ebaab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8281&range=04-05

  Stats: 13 lines in 1 file changed: 4 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8281.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8281/head:pull/8281

PR: https://git.openjdk.java.net/jdk/pull/8281

From duke at openjdk.java.net  Thu May 26 23:25:32 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 26 May 2022 23:25:32 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v5]
In-Reply-To: <-cK9cZaWT49vGfgLRmzTD8S-JEOQ3aCYwNpxp0VuOpA=.9f45f03c-566d-46d4-81cd-75ebf5ffa002@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <RA5sgigVATuc7_Et30DNS8dJZjot7hadEgzon0jl8ew=.079510a5-8bc8-49bb-8105-51ca942e833b@github.com>
 <-wa607VaVrTIMKT959-L87gmz96R0t6LqWbO7dW8oKo=.3ed40d93-b517-417f-9603-0c184e3dcdbf@github.com>
 <5MDBe2EG0rhZZKEacioqcPuYCfWXM-Rdkiab4HHK8O8=.c85bc0cd-a05b-41d7-b5e0-b2b788fa9b77@github.com>
 <-cK9cZaWT49vGfgLRmzTD8S-JEOQ3aCYwNpxp0VuOpA=.9f45f03c-566d-46d4-81cd-75ebf5ffa002@github.com>
Message-ID: <uQsswEA2Jke8z5PL6fTMHlxrnMz4Fs-CG89r-eAy0-w=.b7990d3a-d6d0-40a5-8d65-20839711dd06@github.com>

On Thu, 26 May 2022 22:33:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The original check and `Modules.addOpen` calls were added in [8159476](https://bugs.openjdk.java.net/browse/JDK-8159746), when the `invokeDefault` support was added.
>> 
>> See: https://github.com/openjdk/jdk/commit/56b15fbbcc7c04252f2712d859ff7b820b7c79ad#diff-c15cc774a95bac204c294b9ca8e20332c81904e506e16bb7d5a82d1c30cced17R667, or #313
>
> Ah, I see. That assert was added in PR #313 as a clarification to the current proxy implementation but not required by the `InvocationHandle::invokeDefault`.   It could have been added before the default method support.

It appears to me that it's required by `proxyClassLookup` to perform reflective access on the dynamic module or the module where the package-private interface is located.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From kcr at openjdk.java.net  Thu May 26 23:28:36 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 26 May 2022 23:28:36 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
Message-ID: <xzVcXALL28qJq-ehqZ4nE80Vc9F_pw6dE3kggqVh0e0=.c4c87998-8bf1-4bb1-b443-0f841581da75@github.com>

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by kcr (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From bchristi at openjdk.java.net  Thu May 26 23:41:47 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 26 May 2022 23:41:47 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v6]
In-Reply-To: <jmQIfUsKkd3oe_6JUYbSmIY4ANIhB5tG1twdRQ--ckc=.c9d66a1b-eb9d-4c2e-bf79-00f0d7cb5a29@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <rdd4WNhICmTpUwheAex-YixgZSbjWonmMHsPTlL3g2A=.161547b1-4e23-460c-b93a-39c8258f5876@github.com>
 <jmQIfUsKkd3oe_6JUYbSmIY4ANIhB5tG1twdRQ--ckc=.c9d66a1b-eb9d-4c2e-bf79-00f0d7cb5a29@github.com>
Message-ID: <3omcPbJj0npwQd96BvzsYAzCF50BoN9PCRkqkhUsrKs=.54a5e491-9850-468a-8ab9-3ac3e664a78a@github.com>

On Sat, 23 Apr 2022 00:09:48 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java line 73:
>> 
>>> 71:         public void run() {
>>> 72:             if (enumClnt != null) {
>>> 73:                 enumClnt.clearSearchReply(res, homeCtx.reqCtls);
>> 
>> It's a bit strange to see that there is no guard here to verify that `homeCtx != null`, when line 76 implies that it might. My reading is that `homeCtxt` is not supposed to be `null` when `enumClnt` is not `null`. That could be explained in a comment, or alternatively asserted just before line 73 (`assert homeCtx != null;`)
>
> Yes, it is strange -- that code came from the finalizer. I will add an assert.

It appears that the update() method can set 'homeCtx' for 'ne' to null while leaving 'enumClnt' non-null (~L410).
Perhaps here, the clearSearchReply() call should only happen if both are non-null.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8311

From duke at openjdk.java.net  Thu May 26 23:42:27 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 26 May 2022 23:42:27 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v4]
In-Reply-To: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
Message-ID: <eEwu04kbCUKUccORV0XAY3Qmicd3xuoeyewE7mzfliQ=.964aae9c-bc6d-4f62-8b68-c89462154f5d@github.com>

> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)

liach has updated the pull request incrementally with one additional commit since the last revision:

  Make primitive type info more reader friendly

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8801/files
  - new: https://git.openjdk.java.net/jdk/pull/8801/files/96c0835e..6d171268

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8801&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8801&range=02-03

  Stats: 26 lines in 1 file changed: 7 ins; 1 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8801.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8801/head:pull/8801

PR: https://git.openjdk.java.net/jdk/pull/8801

From duke at openjdk.java.net  Thu May 26 23:42:30 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 26 May 2022 23:42:30 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v3]
In-Reply-To: <yODApM86n4J-SOvOi9O8o5bcERwZPKMSbAoL_u9kec4=.ecbd5d35-d1f0-43d8-bd4d-5c3a472b1b33@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <X_hAi-_31Lxf4hcgul5brgGVxRd64HdjUZFdmkciTqQ=.0e84f6a1-bd55-4efc-8062-2b1ee119fd2d@github.com>
 <yODApM86n4J-SOvOi9O8o5bcERwZPKMSbAoL_u9kec4=.ecbd5d35-d1f0-43d8-bd4d-5c3a472b1b33@github.com>
Message-ID: <DUB_3FY-3HMLBf3LOe1CDctqUuhWPuubRSgS8O-ljpw=.3b591bbf-c4ad-47cd-8967-26871599ceec@github.com>

On Thu, 26 May 2022 22:51:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> liach 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 proxy-primitivetypeinfo
>>  - Convert PrimitiveTypeInfo to an enum
>>  - 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 969:
> 
>> 967:             // single-char BaseType descriptor (see JVMS section 4.3.2)
>> 968:             String baseTypeString = wrapper.basicTypeString();
>> 969:             wrapperClassName = dotToSlash(wrapper.wrapperType().getName());
> 
> Suggestion:
> 
>             wrapperClassName = wrapper.wrapperType().descriptorString();
> 
> 
> It may worth to replace similar use of `dotToSlash(c.getName())` pattern.

Unfortunately, we want an internal name (`xxx/Abc`) than a field descriptor (`Lxxx/Abc;`). But we can use descriptor string for the valueOf descriptor construction.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From duke at openjdk.java.net  Thu May 26 23:49:33 2022
From: duke at openjdk.java.net (liach)
Date: Thu, 26 May 2022 23:49:33 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v3]
In-Reply-To: <yODApM86n4J-SOvOi9O8o5bcERwZPKMSbAoL_u9kec4=.ecbd5d35-d1f0-43d8-bd4d-5c3a472b1b33@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <X_hAi-_31Lxf4hcgul5brgGVxRd64HdjUZFdmkciTqQ=.0e84f6a1-bd55-4efc-8062-2b1ee119fd2d@github.com>
 <yODApM86n4J-SOvOi9O8o5bcERwZPKMSbAoL_u9kec4=.ecbd5d35-d1f0-43d8-bd4d-5c3a472b1b33@github.com>
Message-ID: <MUw5ivahvbZj0BCNbXQiDyBZTU_2cJLFEg6f7nMib9M=.f5cbffa2-6055-40f7-a5fd-a5ce73c3c16a@github.com>

On Thu, 26 May 2022 22:55:02 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> liach 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 proxy-primitivetypeinfo
>>  - Convert PrimitiveTypeInfo to an enum
>>  - 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo
>
> Have you considered including the opcode for load and return instruction instead of `opcodeOffset`?

Hi @mlchung Mandy, I've changed the offset to seperate load and return opcodes, which is more in-line with how other fields in `PrimitiveTypeInfo` are used. In addition, I specified that the `wrapperClassName` is an internal name for clarification. Would you mind review this again, and review #8800, which avoids eager class initialization for parameter types used by proxy?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From mchung at openjdk.java.net  Fri May 27 00:01:37 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 27 May 2022 00:01:37 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v3]
In-Reply-To: <DUB_3FY-3HMLBf3LOe1CDctqUuhWPuubRSgS8O-ljpw=.3b591bbf-c4ad-47cd-8967-26871599ceec@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <X_hAi-_31Lxf4hcgul5brgGVxRd64HdjUZFdmkciTqQ=.0e84f6a1-bd55-4efc-8062-2b1ee119fd2d@github.com>
 <yODApM86n4J-SOvOi9O8o5bcERwZPKMSbAoL_u9kec4=.ecbd5d35-d1f0-43d8-bd4d-5c3a472b1b33@github.com>
 <DUB_3FY-3HMLBf3LOe1CDctqUuhWPuubRSgS8O-ljpw=.3b591bbf-c4ad-47cd-8967-26871599ceec@github.com>
Message-ID: <Mf45RXbuWVrTMGHUl46xDt61-P5wwpFdTRYGu191Wj0=.e8af1779-a4e4-485f-988e-842c03bfa914@github.com>

On Thu, 26 May 2022 23:35:10 GMT, liach <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 969:
>> 
>>> 967:             // single-char BaseType descriptor (see JVMS section 4.3.2)
>>> 968:             String baseTypeString = wrapper.basicTypeString();
>>> 969:             wrapperClassName = dotToSlash(wrapper.wrapperType().getName());
>> 
>> Suggestion:
>> 
>>             wrapperClassName = wrapper.wrapperType().descriptorString();
>> 
>> 
>> It may worth to replace similar use of `dotToSlash(c.getName())` pattern.
>
> Unfortunately, we want an internal name (`xxx/Abc`) than a field descriptor (`Lxxx/Abc;`). But we can use descriptor string for the valueOf descriptor construction.

ah, you're right.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From mchung at openjdk.java.net  Fri May 27 00:01:42 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 27 May 2022 00:01:42 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v4]
In-Reply-To: <eEwu04kbCUKUccORV0XAY3Qmicd3xuoeyewE7mzfliQ=.964aae9c-bc6d-4f62-8b68-c89462154f5d@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <eEwu04kbCUKUccORV0XAY3Qmicd3xuoeyewE7mzfliQ=.964aae9c-bc6d-4f62-8b68-c89462154f5d@github.com>
Message-ID: <SzWOWxd8JuW60G0OE1d7OVNgU2AEvrq3Jtqh1F0wPBQ=.00c01f45-11a8-4285-8328-964d45450c73@github.com>

On Thu, 26 May 2022 23:42:27 GMT, liach <duke at openjdk.java.net> wrote:

>> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make primitive type info more reader friendly

src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 979:

> 977:             unwrapMethodDesc = "()" + baseTypeString;
> 978:             this.loadOpcode = loadOpcode;
> 979:             this.returnOpcode = loadOpcode - ILOAD + IRETURN;

This could do it.  It would be more explicit to take the return opcode as an argument to the constructor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From duke at openjdk.java.net  Fri May 27 00:16:00 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 27 May 2022 00:16:00 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v5]
In-Reply-To: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
Message-ID: <RdOKeNLsX92GgYy00xtxM6Z2wqMEmzaJXK2qkx5ThKs=.5be7f784-8f61-4f62-85a6-f69c45d1f237@github.com>

> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)

liach has updated the pull request incrementally with one additional commit since the last revision:

  Doesn't hurt to be more specific

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8801/files
  - new: https://git.openjdk.java.net/jdk/pull/8801/files/6d171268..6aa89eff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8801&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8801&range=03-04

  Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8801.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8801/head:pull/8801

PR: https://git.openjdk.java.net/jdk/pull/8801

From joehw at openjdk.java.net  Fri May 27 01:20:04 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 27 May 2022 01:20:04 GMT
Subject: RFR: 8284400: Improve XPath exception handling
Message-ID: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>

Address some insufficiency of error handling in the XPath implementation. Some cleanup where appropriate, without attempting to do too much as this is an component that hasn't had much changes for 15 years, a fairly stable application.

-------------

Commit messages:
 - 8284400: Improve XPath exception handling

Changes: https://git.openjdk.java.net/jdk/pull/8910/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8910&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284400
  Stats: 861 lines in 11 files changed: 617 ins; 179 del; 65 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8910.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8910/head:pull/8910

PR: https://git.openjdk.java.net/jdk/pull/8910

From mchung at openjdk.java.net  Fri May 27 02:01:34 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 27 May 2022 02:01:34 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v4]
In-Reply-To: <RbL7fWso4C5Ua4rPTOtsCzO4wq2mAO1JYeqXaNH7xs0=.abcbd42d-60ed-4be0-a5ca-8faee8533d05@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
 <RbL7fWso4C5Ua4rPTOtsCzO4wq2mAO1JYeqXaNH7xs0=.abcbd42d-60ed-4be0-a5ca-8faee8533d05@github.com>
Message-ID: <j8pLIUtcRWOcyTC-7zccuLZ3Pfgn2JkkXYnYd9jWijY=.6f04f911-c503-4ddd-a851-6e659b4abd55@github.com>

On Thu, 26 May 2022 20:52:43 GMT, liach <duke at openjdk.java.net> wrote:

>> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of `Class.forName(String)`. `make test TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new `LazyInitializationTest` failing the eager initialization check on the baseline and passing with this patch.
>> 
>> On a side note, this might reduce the number of methods that can be encoded in a proxy due to code attribute size restrictions; we probably would address that in another issue, as we never mandated a count of methods that the proxy must be able to implement.
>> 
>> Mandy, would you mind review this?
>
> liach 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into proxy-class-forname
>  - Move the try catch block as it doesn't throw checked exceptions
>  - remove unused field
>  - whitespace
>  - Copyright year
>  - typo
>  - 8285401: Proxy class initializer should use 3-arg `Class.forName` to avoid unnecessary class initialization
>  - Test for eager initialization

Thanks for doing this.   It looks okay.   JDK-7194006, having a variant of `Class::forName` that loads the named class with the class loader of the current class, would simplify this.  This can be updated when such an API is defined in the future.

test/jdk/java/lang/reflect/Proxy/LazyInitializationTest.java line 53:

> 51:                 new Class<?>[]{ Intf.class },
> 52:                 (proxy, method, args) -> null);
> 53:         Assert.assertFalse(initialized, "parameter type initialized eagerly");

This expects "parameter type initialized eagerly" to be false.   This may cause confusion to the reader.  Maybe just simply "initialized expected: false" and a comment would help too.  Similarly for line 56.

test/jdk/java/lang/reflect/Proxy/LazyInitializationTest.java line 53:

> 51:                 new Class<?>[]{ Intf.class },
> 52:                 (proxy, method, args) -> null);
> 53:         Assert.assertFalse(initialized, "parameter type initialized eagerly");

This expects "parameter type initialized eagerly" to be false.   This may cause confusion to the reader.  Maybe just simply "initialized expected: false" and a comment would help too.  Similarly for line 56.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8800

From mchung at openjdk.java.net  Fri May 27 02:02:30 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 27 May 2022 02:02:30 GMT
Subject: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v5]
In-Reply-To: <RdOKeNLsX92GgYy00xtxM6Z2wqMEmzaJXK2qkx5ThKs=.5be7f784-8f61-4f62-85a6-f69c45d1f237@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
 <RdOKeNLsX92GgYy00xtxM6Z2wqMEmzaJXK2qkx5ThKs=.5be7f784-8f61-4f62-85a6-f69c45d1f237@github.com>
Message-ID: <O8e09Lu9aw9Sf2R5VNUi2mN5pR5-pQBP8bFWZO-y2XY=.5635a9c6-7598-436b-b623-16770daead8f@github.com>

On Fri, 27 May 2022 00:16:00 GMT, liach <duke at openjdk.java.net> wrote:

>> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Doesn't hurt to be more specific

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From duke at openjdk.java.net  Fri May 27 02:32:43 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 27 May 2022 02:32:43 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v5]
In-Reply-To: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
Message-ID: <dcX87zM5RCXM8ewZRBLSOgTAtQz3CeNr86J7Kk3L4uQ=.81bd1503-c14e-432d-9a8f-61cd9d709f02@github.com>

> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of `Class.forName(String)`. `make test TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new `LazyInitializationTest` failing the eager initialization check on the baseline and passing with this patch.
> 
> On a side note, this might reduce the number of methods that can be encoded in a proxy due to code attribute size restrictions; we probably would address that in another issue, as we never mandated a count of methods that the proxy must be able to implement.
> 
> Mandy, would you mind review this?

liach has updated the pull request incrementally with one additional commit since the last revision:

  Improve test messages

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8800/files
  - new: https://git.openjdk.java.net/jdk/pull/8800/files/1262e8fa..1090df4a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8800&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8800&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8800.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8800/head:pull/8800

PR: https://git.openjdk.java.net/jdk/pull/8800

From duke at openjdk.java.net  Fri May 27 02:32:49 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 27 May 2022 02:32:49 GMT
Subject: RFR: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization [v4]
In-Reply-To: <j8pLIUtcRWOcyTC-7zccuLZ3Pfgn2JkkXYnYd9jWijY=.6f04f911-c503-4ddd-a851-6e659b4abd55@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
 <RbL7fWso4C5Ua4rPTOtsCzO4wq2mAO1JYeqXaNH7xs0=.abcbd42d-60ed-4be0-a5ca-8faee8533d05@github.com>
 <j8pLIUtcRWOcyTC-7zccuLZ3Pfgn2JkkXYnYd9jWijY=.6f04f911-c503-4ddd-a851-6e659b4abd55@github.com>
Message-ID: <KPx9J7stEs4MxI3TvxWxu0u1IPrGM8C1dSoB9p4Eh74=.b2a21e2a-e52f-4009-80b2-24ce36640130@github.com>

On Fri, 27 May 2022 01:55:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> liach 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 eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into proxy-class-forname
>>  - Move the try catch block as it doesn't throw checked exceptions
>>  - remove unused field
>>  - whitespace
>>  - Copyright year
>>  - typo
>>  - 8285401: Proxy class initializer should use 3-arg `Class.forName` to avoid unnecessary class initialization
>>  - Test for eager initialization
>
> test/jdk/java/lang/reflect/Proxy/LazyInitializationTest.java line 53:
> 
>> 51:                 new Class<?>[]{ Intf.class },
>> 52:                 (proxy, method, args) -> null);
>> 53:         Assert.assertFalse(initialized, "parameter type initialized eagerly");
> 
> This expects "parameter type initialized eagerly" to be false.   This may cause confusion to the reader.  Maybe just simply "initialized expected: false" and a comment would help too.  Similarly for line 56.

I renamed the message to "parameter type initialized unnecessarily", which should be more clear.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8800

From darcy at openjdk.java.net  Fri May 27 03:08:39 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 27 May 2022 03:08:39 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <PimNyakuyuROLm8fW2DtGIZpz-0tIi-V3u4ZFCDARe0=.4375bec8-7a2c-4937-ae88-5be8253b6a8d@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
 <PimNyakuyuROLm8fW2DtGIZpz-0tIi-V3u4ZFCDARe0=.4375bec8-7a2c-4937-ae88-5be8253b6a8d@github.com>
Message-ID: <yhXnj-mmkgUnG8UmG2T_5plY3OksB_qaLguIesibOBY=.925073e3-bdd4-44cf-945b-061812318004@github.com>

On Wed, 25 May 2022 19:22:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> AccessFlags.SUPER can/should be removed; it is unused and will be redefined in the [Value Objects JEP](https://openjdk.java.net/jeps/8277163). It will be a cleaner transition if there is no opportunity to create a dependency on the obsolete flag.

Hmm. I don't agree with that conclusion. I see the role of AccessFlags is to model what is in the class file. ACC_SUPER has been documented and in multiple versions of the JVMS and has appeared set in class files. If the bit position is reused, that is fine and the API can accommodate that overlap, unlike a bit-flag based model.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From almatvee at openjdk.java.net  Fri May 27 03:19:00 2022
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 27 May 2022 03:19:00 GMT
Subject: RFR: 8287125: [macos] Multiple jpackage tests fail/timeout on same
 host
Message-ID: <5-MS8JgYU2g0tklV4ccJGGdC1_LTP_RKPI2rTojZLW8=.a450b22c-32b4-4f61-ac1d-211767a03b8a@github.com>

Looks like regression from JDK-8277493. JDK-8277493 will always un-sign app image. Un-signing takes time since we enumerating all files and un-signing binaries one by one. Average increase 2-3 minutes for tests which generates multiple app images. Fixed by increasing timeout for reported tests.

-------------

Commit messages:
 - 8287125: [macos] Multiple jpackage tests fail/timeout on same host

Changes: https://git.openjdk.java.net/jdk/pull/8911/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8911&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287125
  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8911.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8911/head:pull/8911

PR: https://git.openjdk.java.net/jdk/pull/8911

From darcy at openjdk.java.net  Fri May 27 03:36:41 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 27 May 2022 03:36:41 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v3]
In-Reply-To: <WB-jlVcwVv0n9Ut4s8w6a20X-P-qJFIYmxd1DOfau9Y=.665df86a-d1f7-4936-b08c-a2591af44017@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
 <WB-jlVcwVv0n9Ut4s8w6a20X-P-qJFIYmxd1DOfau9Y=.665df86a-d1f7-4936-b08c-a2591af44017@github.com>
Message-ID: <VhZ7YVkvZ5YDYZZ40qRgfdZBk14yQGR8pgD4gcxvty8=.0e165dae-72b9-484e-830c-0b52734f8613@github.com>

On Tue, 24 May 2022 15:15:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>> 
>> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add statement to close about thread termination

src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 668:

> 666:             sb.append('/');
> 667:         }
> 668:         String id = getClass().getName() + "@" + System.identityHashCode(this);

Can use Objects.toIdentityString() instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8787

From iris at openjdk.java.net  Fri May 27 04:04:35 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 27 May 2022 04:04:35 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
Message-ID: <hBtEDFsu7ZcoARe5fQvkS8mAaQji5T0oyobLuw-AWSA=.1329454b-1c6f-4c10-b901-60c8d0041437@github.com>

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From duke at openjdk.java.net  Fri May 27 05:12:43 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 27 May 2022 05:12:43 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v14]
In-Reply-To: <vmYk6F4vkRB2HmpWMmGGHGb1r8W5btmkULpY0mxQGAQ=.0d068364-e67a-4f05-9194-f0044ce52496@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <vmYk6F4vkRB2HmpWMmGGHGb1r8W5btmkULpY0mxQGAQ=.0d068364-e67a-4f05-9194-f0044ce52496@github.com>
Message-ID: <V1CgQaKXLiEKvotKxbX6fBqWRlK2_XOF1F5W4fZNX_o=.9317d8ba-4f35-40ab-bcdb-b7186d9e6a5f@github.com>

On Thu, 26 May 2022 18:08:13 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into fix_8284780
>  - Merge remote-tracking branch 'openjdk/master' into fix_8284780
>    
>    # Conflicts:
>    #	test/jdk/java/util/HashMap/WhiteBoxResizeTest.java
>  - add 8284780 to test
>  - redo the tests
>  - rename items to elements
>  - add test for newHashSet and newLinkedHashSet
>  - revert much too changes for newHashSet
>  - add more replaces
>  - add more replaces
>  - add more replaces
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7cb368b3...117918f4

src/java.base/share/classes/java/util/HashSet.java line 130:

> 128:      * @apiNote
> 129:      * To create a {@code HashSet} with an initial capacity that accommodates
> 130:      * an expected number of items, use {@link #newHashSet(int) newHashSet}.

Suggestion:

     * an expected number of elements, use {@link #newHashSet(int) newHashSet}.

src/java.base/share/classes/java/util/HashSet.java line 147:

> 145:      * @apiNote
> 146:      * To create a {@code HashSet} with an initial capacity that accommodates
> 147:      * an expected number of items, use {@link #newHashSet(int) newHashSet}.

Suggestion:

     * an expected number of elements, use {@link #newHashSet(int) newHashSet}.

src/java.base/share/classes/java/util/HashSet.java line 391:

> 389:      *
> 390:      * @param numElements    the expected number of elements
> 391:      * @param <E>         the type of keys maintained by this set

Suggestion:

     * @param <E> the type of elements maintained by this set

src/java.base/share/classes/java/util/LinkedHashSet.java line 131:

> 129:      * @apiNote
> 130:      * To create a {@code LinkedHashSet} with an initial capacity that accommodates
> 131:      * an expected number of items, use {@link #newLinkedHashSet(int) newLinkedHashSet}.

Suggestion:

     * an expected number of elements, use {@link #newLinkedHashSet(int) newLinkedHashSet}.

src/java.base/share/classes/java/util/LinkedHashSet.java line 148:

> 146:      * @apiNote
> 147:      * To create a {@code LinkedHashSet} with an initial capacity that accommodates
> 148:      * an expected number of items, use {@link #newLinkedHashSet(int) newLinkedHashSet}.

Suggestion:

     * an expected number of elements, use {@link #newLinkedHashSet(int) newLinkedHashSet}.

src/java.base/share/classes/java/util/LinkedHashSet.java line 212:

> 210:      *
> 211:      * @param numElements    the expected number of elements
> 212:      * @param <E>         the type of keys maintained by this set

Suggestion:

     * @param <E> the type of elements maintained by this set

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From smarks at openjdk.java.net  Fri May 27 05:34:51 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 27 May 2022 05:34:51 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v14]
In-Reply-To: <vmYk6F4vkRB2HmpWMmGGHGb1r8W5btmkULpY0mxQGAQ=.0d068364-e67a-4f05-9194-f0044ce52496@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <vmYk6F4vkRB2HmpWMmGGHGb1r8W5btmkULpY0mxQGAQ=.0d068364-e67a-4f05-9194-f0044ce52496@github.com>
Message-ID: <_gO04nLDvvjx4hHbiXzJaVMCe1JeV6u1wgTYMWg3S0E=.444ca8a9-2ceb-4ae1-ab14-9c90e6b040b6@github.com>

On Thu, 26 May 2022 18:08:13 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into fix_8284780
>  - Merge remote-tracking branch 'openjdk/master' into fix_8284780
>    
>    # Conflicts:
>    #	test/jdk/java/util/HashMap/WhiteBoxResizeTest.java
>  - add 8284780 to test
>  - redo the tests
>  - rename items to elements
>  - add test for newHashSet and newLinkedHashSet
>  - revert much too changes for newHashSet
>  - add more replaces
>  - add more replaces
>  - add more replaces
>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7cb368b3...117918f4

Thanks for the updates. I've made a couple minor changes to the specs; please merge the latest commit from this branch:

https://github.com/stuart-marks/jdk/tree/pull/8302

I've created a CSR and have included these changes in it. Please review: [JDK-8287419](https://bugs.openjdk.java.net/browse/JDK-8287419)

I'll look at the test changes later. I wanted to get the CSR moving first, since it will take a few days (and a long weekend in the US is coming up).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Fri May 27 06:10:08 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Fri, 27 May 2022 06:10:08 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v15]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <ImN7TbrB1EiPMyJsYya0WNIKWcGzDyfKzuyMIj5517k=.e564d69b-5fdb-4128-b132-692dd1b4b062@github.com>

> as title.

XenoAmess has updated the pull request incrementally with six additional commits since the last revision:

 - Update src/java.base/share/classes/java/util/LinkedHashSet.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Update src/java.base/share/classes/java/util/LinkedHashSet.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Update src/java.base/share/classes/java/util/LinkedHashSet.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Update src/java.base/share/classes/java/util/HashSet.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Update src/java.base/share/classes/java/util/HashSet.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Update src/java.base/share/classes/java/util/HashSet.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/117918f4..42fba932

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=13-14

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Fri May 27 06:14:13 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Fri, 27 May 2022 06:14:13 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v16]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <Juvt4Tkmuo1LrJUzhRxweZ-N6lgkG2qEYt1GFII81ws=.6fafc48f-ec63-4357-956f-937078d11664@github.com>

> as title.

XenoAmess has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'stuart-marks/pull/8302' into fix_8284780
   
   # Conflicts:
   #	src/java.base/share/classes/java/util/HashSet.java
   #	src/java.base/share/classes/java/util/LinkedHashSet.java
 - Minor terminology fixes: change "item" and "key" to element; remove
   "insertion-ordered" from LinkedHashSet static factory method because
   LHS is implicit insertion-ordered.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/42fba932..230a767e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=14-15

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Fri May 27 06:14:16 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Fri, 27 May 2022 06:14:16 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v14]
In-Reply-To: <_gO04nLDvvjx4hHbiXzJaVMCe1JeV6u1wgTYMWg3S0E=.444ca8a9-2ceb-4ae1-ab14-9c90e6b040b6@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <vmYk6F4vkRB2HmpWMmGGHGb1r8W5btmkULpY0mxQGAQ=.0d068364-e67a-4f05-9194-f0044ce52496@github.com>
 <_gO04nLDvvjx4hHbiXzJaVMCe1JeV6u1wgTYMWg3S0E=.444ca8a9-2ceb-4ae1-ab14-9c90e6b040b6@github.com>
Message-ID: <6kUN9jU2_OUsSLBB_uw1H7b1qb_CGOxsYFNFgyK3hr8=.e791ec0e-64cb-4cf3-81e1-72079b15a151@github.com>

On Fri, 27 May 2022 05:31:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> XenoAmess has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into fix_8284780
>>  - Merge remote-tracking branch 'openjdk/master' into fix_8284780
>>    
>>    # Conflicts:
>>    #	test/jdk/java/util/HashMap/WhiteBoxResizeTest.java
>>  - add 8284780 to test
>>  - redo the tests
>>  - rename items to elements
>>  - add test for newHashSet and newLinkedHashSet
>>  - revert much too changes for newHashSet
>>  - add more replaces
>>  - add more replaces
>>  - add more replaces
>>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7cb368b3...117918f4
>
> Thanks for the updates. I've made a couple minor changes to the specs; please merge the latest commit from this branch:
> 
> https://github.com/stuart-marks/jdk/tree/pull/8302
> 
> I've created a CSR and have included these changes in it. Please review: [JDK-8287419](https://bugs.openjdk.java.net/browse/JDK-8287419)
> 
> I'll look at the test changes later. I wanted to get the CSR moving first, since it will take a few days (and a long weekend in the US is coming up).

@stuart-marks @liach done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From dholmes at openjdk.java.net  Fri May 27 06:22:36 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 27 May 2022 06:22:36 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
Message-ID: <ZQQCEKUqSLliJKT0nvSvkILQOKheOXL6g9D0SJ94FMs=.b89e74c6-f260-4840-b45a-feb1ad126f34@github.com>

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From mcimadamore at openjdk.java.net  Fri May 27 10:56:11 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 27 May 2022 10:56:11 GMT
Subject: RFR: 8287430 MemorySessionImpl::addOrCleanupIfFail does not rethrow
 exceptions
Message-ID: <36Nx6DXetJleJasUGEQ8S_a3p2nbf2FhP5AqcFLUskk=.5c337e5e-947f-425a-a8f4-818b78f13cf8@github.com>

This patch fix a missing rethrow in `MemorySessionImpl::addOrCleanupIfFail`. As noted in the JBS issue, this bug does not affect correctness, but it delays error reporting.

Writing a test for this is nearly impossible, given that (a) a memory resource created against a closed session would be inaccessible by clients (because the session is closed!), and (b) because of the narrow window in which the problem might manifest (for this problem to occur, a session state change would have to occur between the first state check and when the cleanup action list is updated).

-------------

Commit messages:
 - Add more code comments in `MemorySession::addInternal`
 - Initial push

Changes: https://git.openjdk.java.net/jdk/pull/8917/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8917&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287430
  Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8917.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8917/head:pull/8917

PR: https://git.openjdk.java.net/jdk/pull/8917

From mcimadamore at openjdk.java.net  Fri May 27 10:56:11 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 27 May 2022 10:56:11 GMT
Subject: RFR: 8287430  MemorySessionImpl::addOrCleanupIfFail does not
 rethrow exceptions
In-Reply-To: <36Nx6DXetJleJasUGEQ8S_a3p2nbf2FhP5AqcFLUskk=.5c337e5e-947f-425a-a8f4-818b78f13cf8@github.com>
References: <36Nx6DXetJleJasUGEQ8S_a3p2nbf2FhP5AqcFLUskk=.5c337e5e-947f-425a-a8f4-818b78f13cf8@github.com>
Message-ID: <k8np52fCgBfAs5uJbx_dWK1O-5RJ8EDET0G7TMo-nos=.86b3258d-a92a-4d23-8cd0-09af9b6dfa37@github.com>

On Fri, 27 May 2022 10:29:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fix a missing rethrow in `MemorySessionImpl::addOrCleanupIfFail`. As noted in the JBS issue, this bug does not affect correctness, but it delays error reporting.
> 
> Writing a test for this is nearly impossible, given that (a) a memory resource created against a closed session would be inaccessible by clients (because the session is closed!), and (b) because of the narrow window in which the problem might manifest (for this problem to occur, a session state change would have to occur between the first state check and when the cleanup action list is updated).

src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 112:

> 110:         // to the list (and, in case of an add vs. close race, it might happen that the cleanup action will be
> 111:         // called immediately after).
> 112:         resourceList.add(resource);

Note that I've removed the try/catch, as resourceList::add cannot throw the ScopedAccessError singleton (that is only issued in the raw/internal `checkValidState`)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8917

From redestad at openjdk.java.net  Fri May 27 12:15:33 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 May 2022 12:15:33 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently [v4]
In-Reply-To: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
Message-ID: <Ysj1SUhdBP4DVCOAMzycccwprZQ4b-h9Nm2kEpFIrIA=.8354f093-ba69-4e76-97ea-f7cccc43284a@github.com>

> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
> 
> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
> 
> 
> Patched:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Address Mandy review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8881/files
  - new: https://git.openjdk.java.net/jdk/pull/8881/files/612b4ece..bcd79aad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8881&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8881&range=02-03

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8881.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8881/head:pull/8881

PR: https://git.openjdk.java.net/jdk/pull/8881

From redestad at openjdk.java.net  Fri May 27 12:15:33 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 May 2022 12:15:33 GMT
Subject: RFR: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently [v3]
In-Reply-To: <N7FLxaPZtjFR0h5_KeYIhsWswnopoSuX06Ir-Ba8GyY=.691d4e2c-2840-40f1-82cc-fe9487bcd1a8@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
 <N7FLxaPZtjFR0h5_KeYIhsWswnopoSuX06Ir-Ba8GyY=.691d4e2c-2840-40f1-82cc-fe9487bcd1a8@github.com>
Message-ID: <pK1mywwt9NCXOUzt4OCGKAunvErk0fmMZQf_bgfsX_I=.6d0122ec-cc22-4e80-9ed5-036a263608e6@github.com>

On Wed, 25 May 2022 14:13:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
>> 
>> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
>> 
>> Baseline:
>> 
>> Benchmark                                                      Mode  Cnt     Score     Error   Units
>> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
>> 
>> 
>> Patched:
>> 
>> Benchmark                                                      Mode  Cnt     Score     Error   Units
>> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
>> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed correctly taking b1 into account in of(byte, int, int...) (java/lang/String/concat/ImplicitStringConcatShapes.java test failure)

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8881

From redestad at openjdk.java.net  Fri May 27 12:15:34 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 May 2022 12:15:34 GMT
Subject: Integrated: 8287292: Improve TransformKey to pack more kinds of
 transforms efficiently
In-Reply-To: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
References: <mzhBuZcJVIr2OCsx9LWDwW5Q8CQhpR_wxyAkDwVhMBs=.17a23ef0-9ed8-4697-8dd7-b42f1f907bed@github.com>
Message-ID: <yvEwOqqODVRVYdqNmGSazVUDt-xIFvJjB1L1CXtdLR8=.9627eca1-744d-4af7-ad98-63ca9c19eddd@github.com>

On Wed, 25 May 2022 09:38:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows keys to be compacted when all byte values of the key fit in 4 bits, otherwise a byte array is allocated and used. This means that all transforms with a kind value above 15 will be forced to allocate and use array comparisons.
> 
> Removing unused and folding some transforms to ensure all existing kinds can fit snugly within the 0-15 value range realize a minor improvement to footprint, speed and allocation pressure of affected transforms, e.g. ~300bytes/op reduction in the `StringConcatFactoryBootstraps` microbenchmark:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  2048.475 ?  69.887   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3487.311 ?  80.385    B/op
> 
> 
> Patched:
> 
> Benchmark                                                      Mode  Cnt     Score     Error   Units
> SCFB.makeConcatWithConstants                                   avgt   15  1961.985 ? 101.519   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt   15  3156.478 ? 183.600    B/op

This pull request has now been integrated.

Changeset: be933185
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/be93318576896e8f5f9733ae1f7e3e74d63f5594
Stats:     124 lines in 2 files changed: 70 ins; 21 del; 33 mod

8287292: Improve TransformKey to pack more kinds of transforms efficiently

Reviewed-by: jlaskey, jvernee, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8881

From erikj at openjdk.java.net  Fri May 27 12:24:52 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 27 May 2022 12:24:52 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
Message-ID: <nDBC7Dte9wQnZZt57WhgVNtrMWNCH-oTu-0HwGmQXyw=.d4a5f848-a462-45a3-b881-91fa131e4f74@github.com>

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From jpai at openjdk.java.net  Fri May 27 13:06:40 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 27 May 2022 13:06:40 GMT
Subject: RFR: 8287003: InputStreamReader::read() can return zero despite
 writing a char in the buffer
In-Reply-To: <DNKgrHEdMCHUZN1X6wk2bcMm9zW_UDdCXWPgoeuVdIU=.b4d7c426-20e1-48e5-a8a1-029b5d74f5ce@github.com>
References: <DNKgrHEdMCHUZN1X6wk2bcMm9zW_UDdCXWPgoeuVdIU=.b4d7c426-20e1-48e5-a8a1-029b5d74f5ce@github.com>
Message-ID: <fP5x2JxZ64cPDMqCrVmHMXB9h-cUVizyA6otWZ_VMpo=.ac4eca85-9ab3-4d54-b060-ca98dfafae63@github.com>

On Wed, 25 May 2022 23:08:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> If only a leftover `char` remains in the stream, do not add `-1` to the return value in `lockedRead()`.

Looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8895

From rriggs at openjdk.java.net  Fri May 27 13:31:38 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 May 2022 13:31:38 GMT
Subject: RFR: 8287003: InputStreamReader::read() can return zero despite
 writing a char in the buffer
In-Reply-To: <DNKgrHEdMCHUZN1X6wk2bcMm9zW_UDdCXWPgoeuVdIU=.b4d7c426-20e1-48e5-a8a1-029b5d74f5ce@github.com>
References: <DNKgrHEdMCHUZN1X6wk2bcMm9zW_UDdCXWPgoeuVdIU=.b4d7c426-20e1-48e5-a8a1-029b5d74f5ce@github.com>
Message-ID: <gKXGxvqsZusutlUHWtdOw2oxnCDJo6Wz1n0TKZJC0TI=.9ac50317-7065-42ca-a4eb-fd07e951f9a1@github.com>

On Wed, 25 May 2022 23:08:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> If only a leftover `char` remains in the stream, do not add `-1` to the return value in `lockedRead()`.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8895

From redestad at openjdk.java.net  Fri May 27 14:26:02 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 May 2022 14:26:02 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles
Message-ID: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>

In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.

-------------

Commit messages:
 - Move all conversions closer to the edge
 - Merge master
 - Streamline MHs.dropArguments parameter handling
 - Missed correctly taking b1 into account in of(byte, int, int...) (java/lang/String/concat/ImplicitStringConcatShapes.java test failure)
 - Address review comments, fix unsafe shift, rework and remove ofBothArrays
 - Revert unrelated and unverified hashCode change
 - Improve TransformKey to pack more kinds of transforms efficiently

Changes: https://git.openjdk.java.net/jdk/pull/8923/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8923&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287442
  Stats: 46 lines in 3 files changed: 9 ins; 3 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8923.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8923/head:pull/8923

PR: https://git.openjdk.java.net/jdk/pull/8923

From redestad at openjdk.java.net  Fri May 27 14:29:41 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 May 2022 14:29:41 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles
In-Reply-To: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
Message-ID: <pFjaNfpsB7yeu-7REKVaoVmkkFJPg02iP8SZGfMiUIY=.cd37d88f-a7f6-4cea-a167-acc4733693f7@github.com>

On Fri, 27 May 2022 14:18:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.

Another datapoint is the `MethodHandlesDropArguments.interCreate` microbenchmark which explicitly tests `MethodHandles.dropArguments` (with a minimal argument list):

Before:

Benchmark                                                                Mode  Cnt     Score    Error   Units
MethodHandlesDropArguments.interCreate                                   avgt    5   136.778 ?  1.265   ns/op
MethodHandlesDropArguments.interCreate:?gc.alloc.rate.norm               avgt    5   264.020 ?  0.021    B/op

Patch:

Benchmark                                                                Mode  Cnt     Score     Error   Units
MethodHandlesDropArguments.interCreate                                   avgt    5   120.536 ?   3.133   ns/op
MethodHandlesDropArguments.interCreate:?gc.alloc.rate.norm               avgt    5   220.818 ?  41.309    B/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/8923

From redestad at openjdk.java.net  Fri May 27 14:41:45 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 May 2022 14:41:45 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles
In-Reply-To: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
Message-ID: <2-T6brXpi7YfgmmA2Yh7xPb7pyQEIw4gaw7cQDuO4Kw=.e928d982-62c3-43bf-ab47-cdc104b8f33d@github.com>

On Fri, 27 May 2022 14:18:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.

It might be a bit too paranoid in this instance (since we don't keep the array around for long), but not cloning the result of calling `toArray` on an arbitrary and possibly adversary `List` could open up for TOCTOU race bugs / attacks. The existing code was being paranoid and copying and I don't want to weaken something that could have security implications without double- and triple-checking that it's safe to do so.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8923

From bpb at openjdk.java.net  Fri May 27 15:26:43 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 27 May 2022 15:26:43 GMT
Subject: Integrated: 8287003: InputStreamReader::read() can return zero despite
 writing a char in the buffer
In-Reply-To: <DNKgrHEdMCHUZN1X6wk2bcMm9zW_UDdCXWPgoeuVdIU=.b4d7c426-20e1-48e5-a8a1-029b5d74f5ce@github.com>
References: <DNKgrHEdMCHUZN1X6wk2bcMm9zW_UDdCXWPgoeuVdIU=.b4d7c426-20e1-48e5-a8a1-029b5d74f5ce@github.com>
Message-ID: <n-Q4up5xY489uVZwADyeCmjXn_02bAJJZZBc___RS-I=.4efba975-45ad-4381-80d4-61f0ee35c865@github.com>

On Wed, 25 May 2022 23:08:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> If only a leftover `char` remains in the stream, do not add `-1` to the return value in `lockedRead()`.

This pull request has now been integrated.

Changeset: 6520843f
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6520843f86f638fe4d1e5b3358fab5799daca654
Stats:     33 lines in 2 files changed: 24 ins; 1 del; 8 mod

8287003: InputStreamReader::read() can return zero despite writing a char in the buffer

Reviewed-by: jpai, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8895

From robm at openjdk.java.net  Fri May 27 15:33:15 2022
From: robm at openjdk.java.net (Rob McKenna)
Date: Fri, 27 May 2022 15:33:15 GMT
Subject: RFR: 8281695: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java
 fails intermittently in nightly run
Message-ID: <jHdkloNkrJ2mCC1dn-wiI3Ca5-rXgko5u7VwFvIUXE0=.5d4fd48e-0351-475c-a45e-d9c6b41619a4@github.com>

Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work.

-------------

Commit messages:
 - 8281695: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run

Changes: https://git.openjdk.java.net/jdk/pull/8925/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8925&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281695
  Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8925.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8925/head:pull/8925

PR: https://git.openjdk.java.net/jdk/pull/8925

From duke at openjdk.java.net  Fri May 27 15:35:44 2022
From: duke at openjdk.java.net (Rob Spoor)
Date: Fri, 27 May 2022 15:35:44 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles
In-Reply-To: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
Message-ID: <fXEiY3Di1F2EaHpU7e1p8dcETXxMyI5disOiHx7xih4=.a7254cde-5b50-4a87-986f-471456f1f465@github.com>

On Fri, 27 May 2022 14:18:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5266:

> 5264:      */
> 5265:     public static MethodHandle dropArguments(MethodHandle target, int pos, List<Class<?>> valueTypes) {
> 5266:         return dropArguments(target, pos, valueTypes.toArray(new Class<?>[0]).clone(), true);

Isn't this call to `clone()` unnecessary, as `valueTypes.toArray` should either return the passed empty array, or a newly created array?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8923

From rriggs at openjdk.java.net  Fri May 27 15:51:06 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 May 2022 15:51:06 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <nhr3GazH_vLVqk-4467xr1V0B4WcHQxbad2nG5B5YrM=.a8a94976-3e25-4945-95d5-f55c98c90105@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/75552cfd...05cf2d8b

To reinforce the argument not to propagate ACC_SUPER to the new API.
It is NOT currently defined in j.l.reflect.Modifier, so there are no existing dependencies on a symbol.

Class.getModifiers() *never* returns ACC_SUPER; the VM explicitly removes it (since 2007, for all class file versions).
The note in the JVMS spec indicates it is retained only for source compatibility with earlier releases.
The JVMS spec considers the flag to always be set. and It is always unset in the modifiers returned from getModifiers().

Defining the value where it has not been defined before has no useful purpose.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From duke at openjdk.java.net  Fri May 27 16:11:52 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 27 May 2022 16:11:52 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles
In-Reply-To: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
Message-ID: <wTcTF0rZbZJqbQtnclXb_XO1gjF77FDEj1UbwZbzl78=.b7146779-9628-4c74-8de0-be912f4ab6e8@github.com>

On Fri, 27 May 2022 14:18:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.

If `parameterList` is too slow for `List.of` copies the backing parameter types array, wouldn't calling `JavaUtilCollectionAccess::listFromTrustedArray` a better alternative, as it only allocates one wrapper and has better performance on `subList` than `Arrays.copyOfRange`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8923

From duke at openjdk.java.net  Fri May 27 16:11:53 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 27 May 2022 16:11:53 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles
In-Reply-To: <2-T6brXpi7YfgmmA2Yh7xPb7pyQEIw4gaw7cQDuO4Kw=.e928d982-62c3-43bf-ab47-cdc104b8f33d@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <2-T6brXpi7YfgmmA2Yh7xPb7pyQEIw4gaw7cQDuO4Kw=.e928d982-62c3-43bf-ab47-cdc104b8f33d@github.com>
Message-ID: <o8Z5pxW5T1KNsOOF4OPn1BODGmhzEu9l7Xvr7W_hSWw=.87296fc8-3769-4c18-a225-2e06b9bc0476@github.com>

On Fri, 27 May 2022 14:38:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5266:
>> 
>>> 5264:      */
>>> 5265:     public static MethodHandle dropArguments(MethodHandle target, int pos, List<Class<?>> valueTypes) {
>>> 5266:         return dropArguments(target, pos, valueTypes.toArray(new Class<?>[0]).clone(), true);
>> 
>> Isn't this call to `clone()` unnecessary, as `valueTypes.toArray` should either return the passed empty array, or a newly created array?
>
> It might be a bit too paranoid in this instance (since we don't keep the array around for long), but not cloning the result of calling `toArray` on an arbitrary and possibly adversary `List` could open up for TOCTOU race bugs / attacks. The existing code was being paranoid and copying and I don't want to weaken something that could have security implications without double- and triple-checking that it's safe to do so.

You can probably call the `dropArguments` with `false` for `trusted` instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8923

From naoto at openjdk.java.net  Fri May 27 16:26:50 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 27 May 2022 16:26:50 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v16]
In-Reply-To: <Juvt4Tkmuo1LrJUzhRxweZ-N6lgkG2qEYt1GFII81ws=.6fafc48f-ec63-4357-956f-937078d11664@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <Juvt4Tkmuo1LrJUzhRxweZ-N6lgkG2qEYt1GFII81ws=.6fafc48f-ec63-4357-956f-937078d11664@github.com>
Message-ID: <ewjP8erxvypNbHM-xF_uhf5LSsUGWrKkYjfD_6Pgn8I=.149391b6-f4f1-4447-84e8-0a8031cb3e24@github.com>

On Fri, 27 May 2022 06:14:13 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'stuart-marks/pull/8302' into fix_8284780
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/util/HashSet.java
>    #	src/java.base/share/classes/java/util/LinkedHashSet.java
>  - Minor terminology fixes: change "item" and "key" to element; remove
>    "insertion-ordered" from LinkedHashSet static factory method because
>    LHS is implicit insertion-ordered.

src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java line 227:

> 225:         }
> 226:         StringTokenizer tokens = new StringTokenizer(supportedLocaleString);
> 227:         Set<String> tagset = HashSet.newHashSet(tokens.countTokens());

Hi @XenoAmess, during the refactoring of the above `StringTokenizer`, it turned out that this `HashSet` can be replaced with `Set.of()`. So you can leave this piece as it is, as I will take care of it with JDK-8287340.

src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java line 461:

> 459:         }
> 460:         StringTokenizer tokens = new StringTokenizer(supportedLocaleString);
> 461:         Set<String> tagset = HashSet.newHashSet(tokens.countTokens());

Same as above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From lancea at openjdk.java.net  Fri May 27 16:35:32 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 27 May 2022 16:35:32 GMT
Subject: RFR: 8284400: Improve XPath exception handling
In-Reply-To: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
References: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
Message-ID: <J3iCHxqIBLRhSW1a3DGXhIMmIcW_q3J6zcbIaeaC1_w=.10ba443b-10e4-4705-b85a-39202f8c9e6d@github.com>

On Fri, 27 May 2022 01:12:18 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Addresses an insufficiency of error handling in the XPath implementation. Some cleanup where appropriate, without attempting to do too much as this is a component that hasn't had much changes for 15 years, a fairly stable application.
> 
> Test: tier2 passed
> JCK: JCK XML tests passed

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8910

From naoto at openjdk.java.net  Fri May 27 16:55:39 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 27 May 2022 16:55:39 GMT
Subject: RFR: 8284400: Improve XPath exception handling
In-Reply-To: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
References: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
Message-ID: <grWhNUUrKJxWHp0TYW4JxFWcftEDYc0Ls6wjGtEPhLE=.30188139-b2cf-4420-8410-6db59145d238@github.com>

On Fri, 27 May 2022 01:12:18 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Addresses an insufficiency of error handling in the XPath implementation. Some cleanup where appropriate, without attempting to do too much as this is a component that hasn't had much changes for 15 years, a fairly stable application.
> 
> Test: tier2 passed
> JCK: JCK XML tests passed

LGTM. Nit: some files have old copyright years and/or `@LastModified` fields

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8910

From joehw at openjdk.java.net  Fri May 27 17:17:28 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 27 May 2022 17:17:28 GMT
Subject: RFR: 8284400: Improve XPath exception handling [v2]
In-Reply-To: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
References: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
Message-ID: <9WNlZL_TAdA1D6qXn_BkVdZ4rregMXUtOcY5vKjcVXM=.84bc00b2-e8ab-4a1f-a52a-d84bc97dfae7@github.com>

> Addresses an insufficiency of error handling in the XPath implementation. Some cleanup where appropriate, without attempting to do too much as this is a component that hasn't had much changes for 15 years, a fairly stable application.
> 
> Test: tier2 passed
> JCK: JCK XML tests passed

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  update copyright year and LastModified tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8910/files
  - new: https://git.openjdk.java.net/jdk/pull/8910/files/a03cb0d4..12575c95

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8910&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8910&range=00-01

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8910.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8910/head:pull/8910

PR: https://git.openjdk.java.net/jdk/pull/8910

From joehw at openjdk.java.net  Fri May 27 17:17:28 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 27 May 2022 17:17:28 GMT
Subject: RFR: 8284400: Improve XPath exception handling
In-Reply-To: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
References: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
Message-ID: <7aWrUWU5VVRe1ZIg0Hm_gkswbS6V6ugxDBAhlI9nGOY=.065923fd-7c1f-484d-88c4-e650c71d0229@github.com>

On Fri, 27 May 2022 01:12:18 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Addresses an insufficiency of error handling in the XPath implementation. Some cleanup where appropriate, without attempting to do too much as this is a component that hasn't had much changes for 15 years, a fairly stable application.
> 
> Test: tier2 passed
> JCK: JCK XML tests passed

Thanks Lance, Naoto!  Updated copyright year and LastModified tag.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8910

From lancea at openjdk.java.net  Fri May 27 17:25:42 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 27 May 2022 17:25:42 GMT
Subject: RFR: 8284400: Improve XPath exception handling [v2]
In-Reply-To: <9WNlZL_TAdA1D6qXn_BkVdZ4rregMXUtOcY5vKjcVXM=.84bc00b2-e8ab-4a1f-a52a-d84bc97dfae7@github.com>
References: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
 <9WNlZL_TAdA1D6qXn_BkVdZ4rregMXUtOcY5vKjcVXM=.84bc00b2-e8ab-4a1f-a52a-d84bc97dfae7@github.com>
Message-ID: <a1-E5Dq1WbAsyxqLx10H3HERGjSVhertG-YmLxGH8D4=.96aaee60-5d16-44f9-bba1-01dca1d37cb3@github.com>

On Fri, 27 May 2022 17:17:28 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Addresses an insufficiency of error handling in the XPath implementation. Some cleanup where appropriate, without attempting to do too much as this is a component that hasn't had much changes for 15 years, a fairly stable application.
>> 
>> Test: tier2 passed
>> JCK: JCK XML tests passed
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year and LastModified tag

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8910

From bchristi at openjdk.java.net  Fri May 27 17:25:50 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 27 May 2022 17:25:50 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
Message-ID: <5BUv428N3aIJ4uMCXl7skG2eU_GUuXjkChyF4YqfH3c=.b5768b14-76c0-4db7-8309-5aa513e8c57e@github.com>

On Thu, 26 May 2022 18:50:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this test update reviewed?
> 
> The ForceGC could be enhanced by using smaller wait/sleep time, and shared cleaner.
> 
> Thanks,
> Xuelei

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8907

From iris at openjdk.java.net  Fri May 27 17:50:46 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 27 May 2022 17:50:46 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
In-Reply-To: <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <npVAcl67brSwE5kDKPxdAR56H2XwA1szYpoxCkqpl4c=.e62afdc0-1fb2-4361-9dec-ae6cb4a7a3d9@github.com>
Message-ID: <iI20fWu6oqalfNEr-eik3gCtFZ0WHonoiP-su_b-e50=.4a1d00f7-77ed-4657-95b5-1b68953108c5@github.com>

On Thu, 26 May 2022 23:05:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From jvernee at openjdk.java.net  Fri May 27 18:01:35 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 27 May 2022 18:01:35 GMT
Subject: RFR: 8287430  MemorySessionImpl::addOrCleanupIfFail does not
 rethrow exceptions
In-Reply-To: <36Nx6DXetJleJasUGEQ8S_a3p2nbf2FhP5AqcFLUskk=.5c337e5e-947f-425a-a8f4-818b78f13cf8@github.com>
References: <36Nx6DXetJleJasUGEQ8S_a3p2nbf2FhP5AqcFLUskk=.5c337e5e-947f-425a-a8f4-818b78f13cf8@github.com>
Message-ID: <7AHdSps4Xx2pu8MZOBXdb0Ea2-Ar3qjKh4tLbQxTpsY=.4285301f-f93c-4c7b-b288-e87744e10734@github.com>

On Fri, 27 May 2022 10:29:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fix a missing rethrow in `MemorySessionImpl::addOrCleanupIfFail`. As noted in the JBS issue, this bug does not affect correctness, but it delays error reporting.
> 
> Writing a test for this is nearly impossible, given that (a) a memory resource created against a closed session would be inaccessible by clients (because the session is closed!), and (b) because of the narrow window in which the problem might manifest (for this problem to occur, a session state change would have to occur between the first state check and when the cleanup action list is updated).

Marked as reviewed by jvernee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8917

From duke at openjdk.java.net  Fri May 27 18:40:32 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Fri, 27 May 2022 18:40:32 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>

> as title.

XenoAmess has updated the pull request incrementally with one additional commit since the last revision:

  do it as naotoj said

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/230a767e..98bfb0e1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=15-16

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Fri May 27 18:40:33 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Fri, 27 May 2022 18:40:33 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v16]
In-Reply-To: <ewjP8erxvypNbHM-xF_uhf5LSsUGWrKkYjfD_6Pgn8I=.149391b6-f4f1-4447-84e8-0a8031cb3e24@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <Juvt4Tkmuo1LrJUzhRxweZ-N6lgkG2qEYt1GFII81ws=.6fafc48f-ec63-4357-956f-937078d11664@github.com>
 <ewjP8erxvypNbHM-xF_uhf5LSsUGWrKkYjfD_6Pgn8I=.149391b6-f4f1-4447-84e8-0a8031cb3e24@github.com>
Message-ID: <8tWnjvv59ZNFS9hlR9xURbMCQ2LxcMUzTFPi1pIOk38=.1c3b2ffd-4153-4aa6-8af7-aa2a71912348@github.com>

On Fri, 27 May 2022 16:19:56 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'stuart-marks/pull/8302' into fix_8284780
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/util/HashSet.java
>>    #	src/java.base/share/classes/java/util/LinkedHashSet.java
>>  - Minor terminology fixes: change "item" and "key" to element; remove
>>    "insertion-ordered" from LinkedHashSet static factory method because
>>    LHS is implicit insertion-ordered.
>
> src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java line 227:
> 
>> 225:         }
>> 226:         StringTokenizer tokens = new StringTokenizer(supportedLocaleString);
>> 227:         Set<String> tagset = HashSet.newHashSet(tokens.countTokens());
> 
> Hi @XenoAmess, during the refactoring of the above `StringTokenizer`, it turned out that this `HashSet` can be replaced with `Set.of()`. So you can leave this piece as it is, as I will take care of it with JDK-8287340.

@naotoj done.

> src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java line 461:
> 
>> 459:         }
>> 460:         StringTokenizer tokens = new StringTokenizer(supportedLocaleString);
>> 461:         Set<String> tagset = HashSet.newHashSet(tokens.countTokens());
> 
> Same as above.

@naotoj done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Fri May 27 19:13:06 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 27 May 2022 19:13:06 GMT
Subject: RFR: 8287353: Use snippet tag instead of pre tag in Javadoc of
 InterruptedException
Message-ID: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>

8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException

-------------

Commit messages:
 - Use snippet tag instead of pre tag

Changes: https://git.openjdk.java.net/jdk/pull/8400/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8400&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287353
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8400.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8400/head:pull/8400

PR: https://git.openjdk.java.net/jdk/pull/8400

From duke at openjdk.java.net  Fri May 27 19:13:06 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 27 May 2022 19:13:06 GMT
Subject: RFR: 8287353: Use snippet tag instead of pre tag in Javadoc of
 InterruptedException
In-Reply-To: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
References: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
Message-ID: <aCZW2JjQSmaVH6Ow9D177gQHBa_q6R6k1tYYfRmSY9c=.64cf3e3b-3ec3-437d-b7c7-59c922c57791@github.com>

On Tue, 26 Apr 2022 15:04:15 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

> 8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException

If this is a valid change, could someone please create a Jira issue to link to it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8400

From duke at openjdk.java.net  Fri May 27 19:13:07 2022
From: duke at openjdk.java.net (altrisi)
Date: Fri, 27 May 2022 19:13:07 GMT
Subject: RFR: 8287353: Use snippet tag instead of pre tag in Javadoc of
 InterruptedException
In-Reply-To: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
References: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
Message-ID: <WEWSvYcPTG9cxKnnJbdFi6kYmoQzhlI9CdkbQzHx74I=.46480d4c-5a3d-49d3-ad98-33ca3f534183@github.com>

On Tue, 26 Apr 2022 15:04:15 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

> 8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException

(not a maintainer) You can make one yourself in https://bugreport.java.com.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8400

From duke at openjdk.java.net  Fri May 27 19:22:30 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 27 May 2022 19:22:30 GMT
Subject: RFR: 8287353: Use snippet tag instead of pre tag in Javadoc of
 InterruptedException
In-Reply-To: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
References: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
Message-ID: <rmOxs9rfG6kmy_ld-3OPhPRfkB5jE32gqaXWeIwjvbc=.e1e19fbf-9df0-4a32-9821-cbd3934566a3@github.com>

On Tue, 26 Apr 2022 15:04:15 GMT, Thiago Henrique H?pner <duke at openjdk.java.net> wrote:

> 8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException

src/java.base/share/classes/java/lang/InterruptedException.java line 35:

> 33:  * this exception.  The following code can be used to achieve
> 34:  * this effect:
> 35:  * {@snippet:

I recommend using `{@snippet lang=java :` instead, like in https://github.com/openjdk/jdk/blob/6520843f86f638fe4d1e5b3358fab5799daca654/src/java.compiler/share/classes/javax/tools/JavaFileManager.java#L84

-------------

PR: https://git.openjdk.java.net/jdk/pull/8400

From duke at openjdk.java.net  Fri May 27 19:31:26 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 27 May 2022 19:31:26 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles
In-Reply-To: <wTcTF0rZbZJqbQtnclXb_XO1gjF77FDEj1UbwZbzl78=.b7146779-9628-4c74-8de0-be912f4ab6e8@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <wTcTF0rZbZJqbQtnclXb_XO1gjF77FDEj1UbwZbzl78=.b7146779-9628-4c74-8de0-be912f4ab6e8@github.com>
Message-ID: <Quh4MyUgAFpaNiwbCCU0K9q4E0qxREsUegmIJzgRpd8=.65af2d75-f700-455d-ab95-68133d801a5f@github.com>

On Fri, 27 May 2022 16:08:03 GMT, liach <duke at openjdk.java.net> wrote:

> If `parameterList` is too slow for `List.of` copies the backing parameter types array, wouldn't calling `JavaUtilCollectionAccess::listFromTrustedArray` a better alternative, as it only allocates one wrapper and has better performance on `subList` than `Arrays.copyOfRange`?

No, because?`listFromTrustedArray` doesn?t?allow?invocation with?array?classes other?than?`Object[].class`:
https://github.com/openjdk/jdk/blob/6520843f86f638fe4d1e5b3358fab5799daca654/src/java.base/share/classes/java/util/ImmutableCollections.java#L195-L222

-------------

PR: https://git.openjdk.java.net/jdk/pull/8923

From redestad at openjdk.java.net  Fri May 27 19:40:36 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 May 2022 19:40:36 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles
In-Reply-To: <Quh4MyUgAFpaNiwbCCU0K9q4E0qxREsUegmIJzgRpd8=.65af2d75-f700-455d-ab95-68133d801a5f@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
 <wTcTF0rZbZJqbQtnclXb_XO1gjF77FDEj1UbwZbzl78=.b7146779-9628-4c74-8de0-be912f4ab6e8@github.com>
 <Quh4MyUgAFpaNiwbCCU0K9q4E0qxREsUegmIJzgRpd8=.65af2d75-f700-455d-ab95-68133d801a5f@github.com>
Message-ID: <nT8BOCxfMaShxttgjJdluULgifTV8PiBwNAcSZyiZAU=.869b64ec-b703-42ed-8673-0a3a6da1e864@github.com>

On Fri, 27 May 2022 19:27:44 GMT, ExE Boss <duke at openjdk.java.net> wrote:

> If `parameterList` is too slow for `List.of` copies the backing parameter types array, wouldn't calling `JavaUtilCollectionAccess::listFromTrustedArray` a better alternative, as it only allocates one wrapper and has better performance on `subList` than `Arrays.copyOfRange`?

Good observation that `MethodType::parameterList()` is a plausible candidate for `listFromTrustedArray`. That could be a good standalone and orthogonal RFE. 

I recall @rose00 musing about how he'd prefer it if `MethodType` and friends would have been implemented with `List.of`-style immutable lists rather than arrays. While I agree with him in principle we now have a mix of both worlds where we're converting between either representation haphazardly, making the implementation more complex in the process. It seems better for now to streamline the implementation with an early conversion to what we use internally (arrays) and stick with that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8923

From duke at openjdk.java.net  Fri May 27 19:41:21 2022
From: duke at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 27 May 2022 19:41:21 GMT
Subject: RFR: 8287353: Use snippet tag instead of pre tag in Javadoc of
 InterruptedException [v2]
In-Reply-To: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
References: <OXIuWlFf1OaAm4eAyZcYrOoOCn9896HgCIbX1AWScGY=.326f787d-61ba-498a-be23-40f80b39c53f@github.com>
Message-ID: <GL5bf0iaZUtLGO-xONoUp5Wd_uNfYFhjdYzfZrEM3tI=.874a39e6-cf26-407e-bb73-31c3ce458fb7@github.com>

> 8287353: Use snippet tag instead of pre tag in Javadoc of InterruptedException

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Fix pull request comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8400/files
  - new: https://git.openjdk.java.net/jdk/pull/8400/files/6d091b81..f83dde2f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8400&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8400&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8400.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8400/head:pull/8400

PR: https://git.openjdk.java.net/jdk/pull/8400

From duke at openjdk.java.net  Fri May 27 19:43:58 2022
From: duke at openjdk.java.net (Anthony Vanelverdinghe)
Date: Fri, 27 May 2022 19:43:58 GMT
Subject: RFR: 8287440: Typo in package-info.java of java.util.random
Message-ID: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>

The change is trivial, but I'll need help from someone to create a JBS issue & sponsor this PR.

-------------

Commit messages:
 - Copy edit: remove pleonasm

Changes: https://git.openjdk.java.net/jdk/pull/8766/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8766&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287440
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8766.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8766/head:pull/8766

PR: https://git.openjdk.java.net/jdk/pull/8766

From jpai at openjdk.java.net  Fri May 27 19:43:58 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 27 May 2022 19:43:58 GMT
Subject: RFR: 8287440: Typo in package-info.java of java.util.random
In-Reply-To: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
References: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
Message-ID: <jgQY0jJ6lNTlrhj1j-mkamb1g7sKKg7C1do2RFnHL8A=.5e9ccc0a-5ad8-4ae4-a459-4d47486bcfe8@github.com>

On Wed, 18 May 2022 11:45:46 GMT, Anthony Vanelverdinghe <duke at openjdk.java.net> wrote:

> The change is trivial, but I'll need help from someone to create a JBS issue & sponsor this PR.

Hello @anthonyvdotbe, I've created https://bugs.openjdk.java.net/browse/JDK-8287440 for this change. Please edit the title of this PR to "8287440: Typo in package-info.java of java.util.random" so that it triggers the review process.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8766

From darcy at openjdk.java.net  Fri May 27 19:47:44 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 27 May 2022 19:47:44 GMT
Subject: RFR: 8287440: Typo in package-info.java of java.util.random
In-Reply-To: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
References: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
Message-ID: <XXZ6X4Vc1DeZuc4BW56zmHYjeXvMC118h4oX8OVpqds=.b60dc71a-6e2c-4622-9687-f601a5bb40b0@github.com>

On Wed, 18 May 2022 11:45:46 GMT, Anthony Vanelverdinghe <duke at openjdk.java.net> wrote:

> The change is trivial, but I'll need help from someone to create a JBS issue & sponsor this PR.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8766

From redestad at openjdk.java.net  Fri May 27 19:52:30 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 May 2022 19:52:30 GMT
Subject: RFR: 8287442: Reduce list to array conversions in
 java.lang.invoke.MethodHandles [v2]
In-Reply-To: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
References: <2WFK79ndzi_7TQLQ7uYoEK6m9t1z7ylPPe9n44Kwb1M=.56026b56-94ab-4119-b501-e46e4e8cf967@github.com>
Message-ID: <DYJF9LPG0MMHcbI0T3t-Yw_AgWZWqn8pdFTXFHJ6uJs=.6aad3a75-c1d4-46c0-aaa2-fd1c859b4a22@github.com>

> In preparation of #8855 this PR refactors the conversions from `List` to array and array to `List`, reducing the number of conversions when calling `MethodHandles.dropArguments` in particular. This remove about ~5% of allocations on the `StringConcatFactoryBootstraps` microbenchmark.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Review comments, eagerly convert sooner in tryFinally

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8923/files
  - new: https://git.openjdk.java.net/jdk/pull/8923/files/019e2ef8..15ff2125

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8923&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8923&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8923.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8923/head:pull/8923

PR: https://git.openjdk.java.net/jdk/pull/8923

From mchung at openjdk.java.net  Fri May 27 20:01:01 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 27 May 2022 20:01:01 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <xEwvVX_Drza6zQ4mwBBWisMZfxKYi_-jR0FhCTV0rUQ=.2e90d7d1-324b-4d38-937a-47a99e43e478@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/2ff12e53...05cf2d8b

I have the same view as Joe.  `ACC_SUPER` has been specified in JVMS and set in class files of an older version.   If `ACC_SUPER` would be removed from JVMS before this API becomes final, the `AccessFlag` API would be revised and not to define it at that time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From darcy at openjdk.java.net  Fri May 27 20:19:29 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 27 May 2022 20:19:29 GMT
Subject: RFR: 8233760: Result of BigDecimal.toString throws overflow
 exception on new BigDecimal(str)
In-Reply-To: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
References: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
Message-ID: <lDPF7Q46hiUG3XSa-wKcIKttKUj-1MRj_PoK6ZahK6s=.fe5c69cf-0697-4dac-b7b8-c852510c6ba1@github.com>

On Thu, 26 May 2022 18:02:14 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

> BigDecimal(String) currently fails to accept some strings produced by BigDecimal.toString(). This PR removes this limitation.

test/jdk/java/math/BigDecimal/StringConstructor.java line 69:

> 67:         constructWithError("0.01e"+Integer.MIN_VALUE);
> 68:         constructWithError("1e"+((long)Integer.MIN_VALUE-1));
> 69: 

Please add some test cases to demonstrate that the round-tripping that previous did not work is functional after the fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8905

From mchung at openjdk.java.net  Fri May 27 20:25:01 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 27 May 2022 20:25:01 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <apPTENS4Q7-tQYOz53z0pHg-uApVCpkJT2h39SyY9k4=.e6e51e4a-5504-42ce-8bba-e9e8b7169b09@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/43363358...05cf2d8b

With the `AccessFlag` API, what is the role of the `Modifier` API going forward?   [Value Objects JEP](https://openjdk.java.net/jeps/8277163) defines the new `identity` and `value` modifiers.  [PR #698](https://github.com/openjdk/valhalla/pull/698) proposes to add `Modifier.IDENTITY` and `Modifier.VALUE` constants as  the `identity` and `value` modifiers are encoded in a class file using the `ACC_IDENTITY` and `ACC_VALUE` flags.  However, with the new improved `AccessFlag` API, the new flags will be defined in the `AccessFlag` API.  I think we should avoid adding the new flags in `Modifier` and leave it for the existing usage.  Use `AccessFlag` for new features.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From rriggs at openjdk.java.net  Fri May 27 20:31:08 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 May 2022 20:31:08 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <MNumntwIM0AVhg9XdJUgy8vRzUsTn85DeWeZrLArSec=.4d2ce40f-c56f-4896-bb47-a5b813f667b0@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/fb4068e0...05cf2d8b

Please comment here: https://github.com/openjdk/valhalla/pull/698
The AccessFlag API identifies Modifier as *the* primary definition of source elements.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From iris at openjdk.java.net  Fri May 27 20:45:42 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 27 May 2022 20:45:42 GMT
Subject: RFR: 8287440: Typo in package-info.java of java.util.random
In-Reply-To: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
References: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
Message-ID: <mvElzR5KX4GMePYdprROEu9AzOQ_EeD450Kazjoh_uM=.e0a485ab-0143-4eac-9d00-031be5540ce8@github.com>

On Wed, 18 May 2022 11:45:46 GMT, Anthony Vanelverdinghe <duke at openjdk.java.net> wrote:

> The change is trivial, but I'll need help from someone to create a JBS issue & sponsor this PR.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8766

From joehw at openjdk.java.net  Fri May 27 21:50:43 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 27 May 2022 21:50:43 GMT
Subject: Integrated: 8284400: Improve XPath exception handling
In-Reply-To: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
References: <EIQnHcbuq9GnPXZTDB9BVyl70UNjRPso6mYGGXoTY8Y=.39c81160-7260-4ecd-93f3-3d043d75562e@github.com>
Message-ID: <N1n1LJaad9XfL50ueuLjLaerxqjIjwhBQzSO2jNXDfk=.46906a97-c6b4-4565-bb6f-4d34b55a851f@github.com>

On Fri, 27 May 2022 01:12:18 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Addresses an insufficiency of error handling in the XPath implementation. Some cleanup where appropriate, without attempting to do too much as this is a component that hasn't had much changes for 15 years, a fairly stable application.
> 
> Test: tier2 passed
> JCK: JCK XML tests passed

This pull request has now been integrated.

Changeset: ed8e8ac2
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed8e8ac2892af3a0a70b95330e01ec976d3fea3c
Stats:     863 lines in 11 files changed: 617 ins; 179 del; 67 mod

8284400: Improve XPath exception handling

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/8910

From rriggs at openjdk.java.net  Fri May 27 21:56:05 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 May 2022 21:56:05 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <p2Iz1v1UYeYkWwl8U3cUoTMjb2HOP-R8FEfYLxdz_hg=.5f32b89b-2435-44b6-a640-420cafb1093c@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/f2d5c3d7...05cf2d8b

As for retaining SUPER, both SUPER and IDENTITY have location class and according to the BasicAccessFlagTest, the bit patterns should be disjoint....

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From bchristi at openjdk.java.net  Fri May 27 22:00:24 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 27 May 2022 22:00:24 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v7]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <C5KFLmzUVM5DsHLCYlQdxUmmJydOBBmuYDL_PYFIPrM=.537fb342-97ea-468e-a720-312b89da8305@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  Threading-related fixes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8311/files
  - new: https://git.openjdk.java.net/jdk/pull/8311/files/a48a56cc..ef8c1410

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=05-06

  Stats: 371 lines in 5 files changed: 122 ins; 87 del; 162 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

PR: https://git.openjdk.java.net/jdk/pull/8311

From duke at openjdk.java.net  Fri May 27 22:03:42 2022
From: duke at openjdk.java.net (liach)
Date: Fri, 27 May 2022 22:03:42 GMT
Subject: Withdrawn: JDK-8242888: Convert dynamic proxy to hidden classes
In-Reply-To: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
References: <-NKQ4V2UzhsLM3cxc-KtBk7Po9HfBKM5xgc-IxlMjWg=.cac6bf36-b71e-415f-b7d2-fb1d481a5490@github.com>
Message-ID: <ppcL2m0gJ62Bb0w5viqE8FNaL5CDE3mpCYhPTsHW-bc=.1baac4f2-ca64-4c79-a99a-9af6224f5acf@github.com>

On Sun, 17 Apr 2022 16:17:30 GMT, liach <duke at openjdk.java.net> wrote:

> Convert dynamic proxies to hidden classes. Modifies the serialization of proxies (requires change in "Java Object Serialization Specification"). Makes the proxies hidden in stack traces. Removes duplicate logic in proxy building.
> 
> The main compatibility changes and their rationales are:
> 1. Modification to the serialization specification: In the "An instance of the class is allocated... The contents restored appropriately" section, I propose explicitly state that handling of proxies are unspecified as to allow implementation freedom, though I've seen deliberate attempts for proxies to implement interfaces with `readResolve` in order to control their serialization behavior.
>    - This is for the existing generated constructor accessor is bytecode-based, which cannot refer to hidden classes.
>    - An alternative is to preserve the behavior, where the serialization constructor calls `invokespecial` on the closest serializable superclass' no-arg constructor, like in #1830 by @DasBrain.
>    - My rationale against preservation is such super calls are unsafe and should be discouraged in the long term. Calling the existing constructor with a dummy argument, as in my implementation, would be more safe.
> 2. The disappearance of proxies in stack traces.
>    - Same behavior exists in lambda expressions: For instance, in `((Runnable) () -> { throw new Error(); }).run();`, the `run` method, implemented by the lambda, will not appear in the stack trace, and isn't too problematic.
> 
> A summary of the rest of the changes:
> 1. Merged the two passes of determining module and package of the proxy into one. This reduced a lot of code and allowed anchor class (for hidden class creation) selection be done together as well.
> 2. Exposed internal API for obtaining a full-privileged lookup to the rest of `java.base`. This API is intended for implementation of legacy (pre `MethodHandles.Lookup`) caller sensitive public APIs so they don't need more complex tricks to obtain proper permissions as lookups.
> 3. Implements [8229959](https://bugs.openjdk.java.net/browse/JDK-8229959): passes methods computed by proxy generator as class data to the hidden proxy class to reduce generated proxy class size and improve performance.
> 
> In addition, since this change is somewhat large, should we keep the old proxy generator as well and have it toggled through a command-line flag (like the old v49 proxy generator or the old reflection implementation)?
> 
> Please feel free to comment or review. This change definitely requires a CSR, but I have yet to determine what specifications should be changed.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8278

From bchristi at openjdk.java.net  Fri May 27 22:05:50 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 27 May 2022 22:05:50 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v7]
In-Reply-To: <C5KFLmzUVM5DsHLCYlQdxUmmJydOBBmuYDL_PYFIPrM=.537fb342-97ea-468e-a720-312b89da8305@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
 <C5KFLmzUVM5DsHLCYlQdxUmmJydOBBmuYDL_PYFIPrM=.537fb342-97ea-468e-a720-312b89da8305@github.com>
Message-ID: <A_s9GFIG6SxDhoeaisCE1SbGnihORw3QZL17hlxf5Dg=.19e6f670-b9c2-48a9-937e-ebb1fa7f42f2@github.com>

On Fri, 27 May 2022 22:00:24 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
>> 
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
>> 
>> Details of note: 
>> 1. Some operations need to change the state values (the update() method is probably the most interesting).
>> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
>> 
>> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
>> 
>> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
>> 
>> Thanks.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Threading-related fixes

`AbstractLdapEnumeration`'s mutable state brings the possibility of threading issues between the program and cleaner threads. I've added some threading-related changes to the fix. See my [comment in the bug report](https://bugs.openjdk.java.net/browse/JDK-8283660?focusedCommentId=14498566&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14498566) for additional background.

Since synchronization may now happen on the cleaner thread, I've changed `AbstractLdapEnumeration` to use its own `Cleaner` instance instead of the shared cleaner, for added safety. There have been deadlocks in ldap cleanup in the past.

The added `finally` blocks led to a lot of indentation changes. The "hide whitespace" option might help with viewing the changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8311

From bchristi at openjdk.java.net  Fri May 27 22:09:22 2022
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 27 May 2022 22:09:22 GMT
Subject: RFR: 8283660: Convert
 com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java finalizer to Cleaner [v8]
In-Reply-To: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
References: <anHLuO0INa29U7GueBX7ihMfveqROF8YXaT0KhPJjdQ=.1a650b8b-45fc-4142-96d4-25839a564b68@github.com>
Message-ID: <TFfoZggVYdxgixJVMjv2EmjpFa2TvhR5S1glroKtVZQ=.8c74410c-de70-41b2-abba-fa73d1b3ac0a@github.com>

> Please review this change to replace the finalizer in `AbstractLdapNamingEnumeration` with a Cleaner.
> 
> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`, and `LdapClient enumClnt`) are moved to a static inner class . From there, the change is fairly mechanical.
> 
> Details of note: 
> 1. Some operations need to change the state values (the update() method is probably the most interesting).
> 2. Subclasses need to access `homeCtx`; I added a `homeCtx()` method to read `homeCtx` from the superclass's `state`.
> 
> The test case is based on a copy of `com/sun/jndi/ldap/blits/AddTests/AddNewEntry.java`. A more minimal test case might be possible, but this was done for expediency.
> 
> The test only confirms that the new Cleaner use does not keep the object reachable. It only tests `LdapSearchEnumeration` (not `LdapNamingEnumeration` or `LdapBindingEnumeration`, though all are subclasses of `AbstractLdapNamingEnumeration`). 
> 
> Thanks.

Brent Christian has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into remove-finalizers
 - Threading-related fixes
 - NOW it builds
 - Fix the merge fix
 - Fix merge
 - Merge
 - Rename inner class to EnumCtx ; use homeCtx() in AbstractLdapNamingEnumeration for consistencty ; new instance vars can be final
 - fix whitespace
 - Merge branch 'master' into remove-finalizers
 - Test changes to test new cleaner code
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/ed8e8ac2...4af66bff

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8311/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8311&range=07
  Stats: 579 lines in 6 files changed: 309 ins; 101 del; 169 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8311.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8311/head:pull/8311

PR: https://git.openjdk.java.net/jdk/pull/8311

From duke at openjdk.java.net  Fri May 27 22:59:47 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 27 May 2022 22:59:47 GMT
Subject: RFR: 8233760: Result of BigDecimal.toString throws overflow
 exception on new BigDecimal(str) [v2]
In-Reply-To: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
References: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
Message-ID: <hUxp38C5zmOoZ1yOPZsLZEDkWfW8xBuPV2eY8k4091A=.50baa789-82bc-4c15-89cb-e399caf9cffd@github.com>

> BigDecimal(String) currently fails to accept some strings produced by BigDecimal.toString(). This PR removes this limitation.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8905/files
  - new: https://git.openjdk.java.net/jdk/pull/8905/files/e82cece0..2a25c359

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8905&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8905&range=00-01

  Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8905.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8905/head:pull/8905

PR: https://git.openjdk.java.net/jdk/pull/8905

From duke at openjdk.java.net  Fri May 27 23:07:34 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 27 May 2022 23:07:34 GMT
Subject: RFR: 8233760: Result of BigDecimal.toString throws overflow
 exception on new BigDecimal(str) [v2]
In-Reply-To: <lDPF7Q46hiUG3XSa-wKcIKttKUj-1MRj_PoK6ZahK6s=.fe5c69cf-0697-4dac-b7b8-c852510c6ba1@github.com>
References: <Bz3wIL26W_O-QCnUW4t38YTos2fQh_WSRtD8nW5EiAk=.0f90eea3-0c74-4ebd-9855-a72c9eb03e31@github.com>
 <lDPF7Q46hiUG3XSa-wKcIKttKUj-1MRj_PoK6ZahK6s=.fe5c69cf-0697-4dac-b7b8-c852510c6ba1@github.com>
Message-ID: <vyHgp2TUtXicPGUFAAh39x7M9ib-40cce_0nO7Q4yHc=.12605ac0-2a1e-4a22-aeb8-e00f632d0409@github.com>

On Fri, 27 May 2022 20:16:12 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str)
>
> test/jdk/java/math/BigDecimal/StringConstructor.java line 69:
> 
>> 67:         constructWithError("0.01e"+Integer.MIN_VALUE);
>> 68:         constructWithError("1e"+((long)Integer.MIN_VALUE-1));
>> 69: 
> 
> Please add some test cases to demonstrate that the round-tripping that previous did not work is functional after the fix.

Tests were added in the new commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8905

From darcy at openjdk.java.net  Sat May 28 00:47:32 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 28 May 2022 00:47:32 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <p2Iz1v1UYeYkWwl8U3cUoTMjb2HOP-R8FEfYLxdz_hg=.5f32b89b-2435-44b6-a640-420cafb1093c@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
 <p2Iz1v1UYeYkWwl8U3cUoTMjb2HOP-R8FEfYLxdz_hg=.5f32b89b-2435-44b6-a640-420cafb1093c@github.com>
Message-ID: <57rhig2JpE1K_9icaKaQsgr8NGuT69iL6GbBipMbuKc=.03e99611-bc2f-41d6-ae48-cebd17d90df5@github.com>

On Fri, 27 May 2022 21:53:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> As for retaining SUPER, both SUPER and IDENTITY have location class and according to the BasicAccessFlagTest, the bit patterns should be disjoint....

If the defined set of class locations, considered over time, have non-disjoint definitions, then the test would need to be modified accordingly of course.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From ysuenaga at openjdk.java.net  Sat May 28 02:12:43 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 28 May 2022 02:12:43 GMT
Subject: Integrated: 8286562: GCC 12 reports some compiler warnings
In-Reply-To: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
Message-ID: <z9gUrUcQpL8GQQzN-sR2qAj2iFOLnp_hho0Lx-uf-DY=.7b48088e-5c9d-430f-b2d9-4e5d620d390f@github.com>

On Wed, 11 May 2022 05:58:31 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
> 
> * -Wstringop-overflow
>     * src/hotspot/share/oops/array.hpp
>     * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
> 
> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>     inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>     inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>     inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:

This pull request has now been integrated.

Changeset: 410a25d5
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/410a25d59a11b6a627bbb0a2c405c2c2be19f464
Stats:     41 lines in 5 files changed: 26 ins; 1 del; 14 mod

8286562: GCC 12 reports some compiler warnings

Reviewed-by: ihse, kbarrett, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/8646

From david.holmes at oracle.com  Sat May 28 05:44:41 2022
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 28 May 2022 15:44:41 +1000
Subject: Integrated: 8286562: GCC 12 reports some compiler warnings
In-Reply-To: <z9gUrUcQpL8GQQzN-sR2qAj2iFOLnp_hho0Lx-uf-DY=.7b48088e-5c9d-430f-b2d9-4e5d620d390f@github.com>
References: <nl3F3sVgfRuKU2apUma_y6LBsnkX948n2Uo2ANqc9jA=.958ff489-2787-4c76-8878-32041db44f86@github.com>
 <z9gUrUcQpL8GQQzN-sR2qAj2iFOLnp_hho0Lx-uf-DY=.7b48088e-5c9d-430f-b2d9-4e5d620d390f@github.com>
Message-ID: <a36c4221-bc04-c23e-da33-c845f4f835f3@oracle.com>

The new assertion in src/hotspot/share/utilities/globalDefinitions.hpp

inline const char* type2name(BasicType t) {
   assert((uint)t < T_CONFLICT + 1, "invalid type");
   return type2name_tab[t];
}

is failing with test

compiler/jvmci/errors/TestInvalidDebugInfo.java

I have filed:

https://bugs.openjdk.java.net/browse/JDK-8287491

The test will probably need ProblemListing as it is causing major noise 
in our CI.

David

On 28/05/2022 12:12 pm, Yasumasa Suenaga wrote:
> On Wed, 11 May 2022 05:58:31 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:
> 
>> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36.
>> As you can see, the warnings spreads several areas. Let me know if I should separate them by area.
>>
>> * -Wstringop-overflow
>>      * src/hotspot/share/oops/array.hpp
>>      * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp
>>
>> In member function 'void Array<T>::at_put(int, const T&) [with T = unsigned char]',
>>      inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64,
>>      inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15,
>>      inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26:
> 
> This pull request has now been integrated.
> 
> Changeset: 410a25d5
> Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
> URL:       https://git.openjdk.java.net/jdk/commit/410a25d59a11b6a627bbb0a2c405c2c2be19f464
> Stats:     41 lines in 5 files changed: 26 ins; 1 del; 14 mod
> 
> 8286562: GCC 12 reports some compiler warnings
> 
> Reviewed-by: ihse, kbarrett, prr
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/8646

From ysuenaga at openjdk.java.net  Sat May 28 07:59:04 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 28 May 2022 07:59:04 GMT
Subject: RFR: 8287363: null pointer should use NULL instead of 0
Message-ID: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>

We found using `0` as `NULL` in java_md_common.c . `0` is not a pointer, so we should use `NULL` where we want to handle it.

https://github.com/openjdk/jdk/pull/8646#discussion_r882294076

Also I found using `0` as NUL char in java_md_common.c , so I replaced it to `\0` in this PR.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into JDK-8287363
 - 8287363: null pointer should use NULL instead of 0

Changes: https://git.openjdk.java.net/jdk/pull/8931/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8931&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287363
  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8931.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8931/head:pull/8931

PR: https://git.openjdk.java.net/jdk/pull/8931

From duke at openjdk.java.net  Sat May 28 09:43:30 2022
From: duke at openjdk.java.net (kristylee88)
Date: Sat, 28 May 2022 09:43:30 GMT
Subject: RFR: 8287363: null pointer should use NULL instead of 0
In-Reply-To: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>
References: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>
Message-ID: <QYQkk9HdddNfI2e_7AsI53WCvLU1Fcs6mgYtYdW5D1g=.d3660f3c-1031-4295-90d8-2078c2b5fd65@github.com>

On Sat, 28 May 2022 03:31:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We found using `0` as `NULL` in java_md_common.c . `0` is not a pointer, so we should use `NULL` where we want to handle it.
> 
> https://github.com/openjdk/jdk/pull/8646#discussion_r882294076
> 
> Also I found using `0` as NUL char in java_md_common.c , so I replaced it to `\0` in this PR.

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8931

From jpai at openjdk.java.net  Sat May 28 10:04:41 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 28 May 2022 10:04:41 GMT
Subject: RFR: 8287440: Typo in package-info.java of java.util.random
In-Reply-To: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
References: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
Message-ID: <RJQ2OwhuXMhltjKamTsdvll7-KQDI-4S9PGt9d7j0NY=.e6f3e883-1faa-4fad-8966-ed99091ee32d@github.com>

On Wed, 18 May 2022 11:45:46 GMT, Anthony Vanelverdinghe <duke at openjdk.java.net> wrote:

> The change is trivial, but I'll need help from someone to create a JBS issue & sponsor this PR.

@anthonyvdotbe, can you also please change the copyright year on that file from `Copyright (c) 2021,` to `Copyright (c) 2021, 2022,`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8766

From duke at openjdk.java.net  Sat May 28 11:56:23 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Sat, 28 May 2022 11:56:23 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
Message-ID: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>

Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

-------------

Commit messages:
 - 8287171: Refactor null caller tests to a single directory

Changes: https://git.openjdk.java.net/jdk/pull/8934/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287171
  Stats: 1293 lines in 18 files changed: 511 ins; 780 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934

From duke at openjdk.java.net  Sat May 28 12:05:31 2022
From: duke at openjdk.java.net (Anthony Vanelverdinghe)
Date: Sat, 28 May 2022 12:05:31 GMT
Subject: RFR: 8287440: Typo in package-info.java of java.util.random [v2]
In-Reply-To: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
References: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
Message-ID: <-Shw-DX9u8uRlnLhypTrBC_j6ty51nYAGB1R5Km7cDs=.a5be8330-442f-491d-9263-06453adad461@github.com>

> The change is trivial, but I'll need help from someone to create a JBS issue & sponsor this PR.

Anthony Vanelverdinghe has updated the pull request incrementally with one additional commit since the last revision:

  Correct copyright year
  
  Signed-off-by: Anthony Vanelverdinghe <dev at anthonyv.be>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8766/files
  - new: https://git.openjdk.java.net/jdk/pull/8766/files/1ed395f3..aeb62f1b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8766&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8766&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8766.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8766/head:pull/8766

PR: https://git.openjdk.java.net/jdk/pull/8766

From duke at openjdk.java.net  Sat May 28 12:05:32 2022
From: duke at openjdk.java.net (Anthony Vanelverdinghe)
Date: Sat, 28 May 2022 12:05:32 GMT
Subject: RFR: 8287440: Typo in package-info.java of java.util.random
In-Reply-To: <RJQ2OwhuXMhltjKamTsdvll7-KQDI-4S9PGt9d7j0NY=.e6f3e883-1faa-4fad-8966-ed99091ee32d@github.com>
References: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
 <RJQ2OwhuXMhltjKamTsdvll7-KQDI-4S9PGt9d7j0NY=.e6f3e883-1faa-4fad-8966-ed99091ee32d@github.com>
Message-ID: <GcoVc8GIqhKfOrTo8GsFr7CGDBwEX0Ug53uA6pc65Ig=.4cf1b014-8161-456d-8dbf-c8cb762f3fcc@github.com>

On Sat, 28 May 2022 10:00:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The change is trivial, but I'll need help from someone to create a JBS issue & sponsor this PR.
>
> @anthonyvdotbe, can you also please change the copyright year on that file from `Copyright (c) 2021,` to `Copyright (c) 2021, 2022,`

Thanks for the heads-up @jaikiran I've fixed the copyright year

-------------

PR: https://git.openjdk.java.net/jdk/pull/8766

From jpai at openjdk.java.net  Sat May 28 14:09:46 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 28 May 2022 14:09:46 GMT
Subject: RFR: 8287440: Typo in package-info.java of java.util.random [v2]
In-Reply-To: <-Shw-DX9u8uRlnLhypTrBC_j6ty51nYAGB1R5Km7cDs=.a5be8330-442f-491d-9263-06453adad461@github.com>
References: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
 <-Shw-DX9u8uRlnLhypTrBC_j6ty51nYAGB1R5Km7cDs=.a5be8330-442f-491d-9263-06453adad461@github.com>
Message-ID: <-lxZ66JVAsY5B12WlkTt37Se4IvudJW3LPoOT2e6VRk=.7cff1eda-0e52-4d6c-9ffb-64eec72bcb41@github.com>

On Sat, 28 May 2022 12:05:31 GMT, Anthony Vanelverdinghe <duke at openjdk.java.net> wrote:

>> The change is trivial, but I'll need help from someone to create a JBS issue & sponsor this PR.
>
> Anthony Vanelverdinghe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct copyright year
>   
>   Signed-off-by: Anthony Vanelverdinghe <dev at anthonyv.be>

Marked as reviewed by jpai (Reviewer).

Thank you for the changes. Looks fine to me. Please go ahead and issue the integrate command and one of us will sponsor this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8766

From kbarrett at openjdk.java.net  Sun May 29 01:48:33 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 29 May 2022 01:48:33 GMT
Subject: RFR: 8287363: null pointer should use NULL instead of 0
In-Reply-To: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>
References: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>
Message-ID: <DnHDd1eBfQQVwofPU4kQfkIMIZgvsrVNdmktvMtUZQY=.ec2efd7b-8cc4-43e2-bfaf-a0bfae9e1114@github.com>

On Sat, 28 May 2022 03:31:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We found using `0` as `NULL` in java_md_common.c . `0` is not a pointer, so we should use `NULL` where we want to handle it.
> 
> https://github.com/openjdk/jdk/pull/8646#discussion_r882294076
> 
> Also I found using `0` as NUL char in java_md_common.c , so I replaced it to `\0` in this PR.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8931

From stuefe at openjdk.java.net  Sun May 29 06:11:40 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sun, 29 May 2022 06:11:40 GMT
Subject: RFR: 8287363: null pointer should use NULL instead of 0
In-Reply-To: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>
References: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>
Message-ID: <JMgAcXmhfy3XjtnlLIFAFkJq5aJRKgjtNpB3K1xamEU=.7929af16-9894-450b-a40b-e4b00ef3c503@github.com>

On Sat, 28 May 2022 03:31:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We found using `0` as `NULL` in java_md_common.c . `0` is not a pointer, so we should use `NULL` where we want to handle it.
> 
> https://github.com/openjdk/jdk/pull/8646#discussion_r882294076
> 
> Also I found using `0` as NUL char in java_md_common.c , so I replaced it to `\0` in this PR.

+1

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8931

From aturbanov at openjdk.java.net  Sun May 29 14:08:06 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sun, 29 May 2022 14:08:06 GMT
Subject: RFR: 8287497: Use String.contains() instead of String.indexOf() in
 java.naming
Message-ID: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>

`String.contains` was introduced in Java 5.
Some code in java.naming still uses old approach with `String.indexOf` to check if String contains specified substring.
I propose to migrate such usages. Makes code shorter and easier to read.

-------------

Commit messages:
 - [PATCH] Use String.contains() instead of String.indexOf() in java.naming

Changes: https://git.openjdk.java.net/jdk/pull/8938/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8938&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287497
  Stats: 13 lines in 4 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8938/head:pull/8938

PR: https://git.openjdk.java.net/jdk/pull/8938

From duke at openjdk.java.net  Sun May 29 14:30:39 2022
From: duke at openjdk.java.net (Anthony Vanelverdinghe)
Date: Sun, 29 May 2022 14:30:39 GMT
Subject: Integrated: 8287440: Typo in package-info.java of java.util.random
In-Reply-To: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
References: <D4V6PmiPamUCQ1ntn_qqufBUQ0cVZDvGzWJ9VN5DE_o=.fda3bde2-d45a-454b-809a-73ea7bdbb79b@github.com>
Message-ID: <M3qFSJUcgxdILbmne50pciVJhsuC4TdVEDftwfBbrcE=.ad552821-23cf-4c23-b116-f9093434e37f@github.com>

On Wed, 18 May 2022 11:45:46 GMT, Anthony Vanelverdinghe <duke at openjdk.java.net> wrote:

> The change is trivial, but I'll need help from someone to create a JBS issue & sponsor this PR.

This pull request has now been integrated.

Changeset: 3d2d0395
Author:    Anthony Vanelverdinghe <dev at anthonyv.be>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3d2d039538b906cedd9188ed94b7ba55c275ff7f
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8287440: Typo in package-info.java of java.util.random

Reviewed-by: darcy, iris, jpai

-------------

PR: https://git.openjdk.java.net/jdk/pull/8766

From duke at openjdk.java.net  Sun May 29 16:44:40 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Sun, 29 May 2022 16:44:40 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v2]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <IeQHTbMwEPicO9-5Hw_gKs-FfmoPD2AbjcyegaxRUmk=.717d05c1-1736-4c66-ad3f-48c866ef517c@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

Tim Prinzing 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 JDK-8287171
 - 8287171: Refactor null caller tests to a single directory

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/5eba965b..a54aa747

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=00-01

  Stats: 2803 lines in 65 files changed: 1631 ins; 617 del; 555 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934

From skuksenko at openjdk.java.net  Sun May 29 17:54:46 2022
From: skuksenko at openjdk.java.net (Sergey Kuksenko)
Date: Sun, 29 May 2022 17:54:46 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v15]
In-Reply-To: <u1LwXpHdXo-gTNdxmPgr5sSznS_pvHTY7FKX709TrEc=.9bb13c80-9015-49be-bf55-b8b461385049@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
 <2upOvyHn5d_AceCQzZhKkoQ0TnGLi_B60ZbsFaT13Sw=.52222cbf-b7fa-47fb-a876-73dfb1bb4f81@github.com>
 <u1LwXpHdXo-gTNdxmPgr5sSznS_pvHTY7FKX709TrEc=.9bb13c80-9015-49be-bf55-b8b461385049@github.com>
Message-ID: <10PwwQSYhhhCDB2YmTPtVaLIBxyl8Qvr0WWbm1msUok=.99a3d26e-cc1f-4392-b629-b4810ddd6f59@github.com>

On Thu, 26 May 2022 15:43:57 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> > Is there any practical scenario where the current code (skip buffer allocation on each invocation) creates issues?
> 
> @kuksenko Not found any yet :)

In that case, what is the value of this PR? Do we need a code change for the sake of code change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From skuksenko at openjdk.java.net  Sun May 29 18:18:00 2022
From: skuksenko at openjdk.java.net (Sergey Kuksenko)
Date: Sun, 29 May 2022 18:18:00 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v15]
In-Reply-To: <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
Message-ID: <RKHI2lmf0kIgp6Ml9JdkusKVWbfTW8sD_j6aTiBQDco=.f4086d6f-7325-4237-8739-d19eb5bde0a4@github.com>

On Tue, 24 May 2022 20:40:51 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   invert if; refine javadoc.

More practically.
This PR has a noticeable negative effect - it increases the size of InputStream objects. Moreover, it increases the size of InputStream subclasses which has own skip() implementation and don't need this superclass modification.

Let's look into InputStream subclasses.
I've checked 51 InputStream from classlib. 30 of them either have their own skip() implementation or use super.skip() other than from InputStream. This PR is definitely harmful to these 30 classes. These 30 classes can be divided into the following categories:

1) Clean non-allocating skip() implementation (22 classes):
 - BufferedInputStream (java.io) 
 - ByteArrayInputStream (java.io)
 - FileInputStream (java.io) 
 - FilterInputStream (java.io)
 - PeekInputStream in ObjectInputStream (java.io)
 - BlockDataInputStream in ObjectInputStream (java.io) 
 - PushbackInputStream (java.io) 
 - FastInputStream in Manifest (java.util.jar)
 - ZipFileInputStream in ZipFile (java.util.zip)
 - CipherInputStream (javax.crypto)
 - MeteredStream (sun.net.www)
 - Anonymous in nullInputStream() in InputStream (java.io)
 - DataInputStream (java.io)
 - Anonymous in readTrailer() in GZIPInputStream (java.util.zip)
 - FtpInputStream in FtpURLConnection (sun.net.www.protocol.ftp)
 - JarURLInputStream in JarURLConnection (sun.net.www.protocol.jar)
 - PlainTextInputStream (sun.net.www.content.text)
 - PushbackInputStream (java.io)
 - TelnetInputStream (sun.net)
 - UnclosableInputStream in FileInputStreamPool (sun.security.provider)
 - MeteredStream (sun.net.www)
 - KeepAliveStream (sun.net.www.http)

2) Partially clean skip() implementation (1 class):
 - ChannelInputStream (sun.nio.ch)
   Note: clean skip impl when using SeekableByteChannel (most usages) otherwise super.skip() is used, and it may be easily rewritten using the existing internal buffer.

3) Unavoidable skip buffers (7 classes):
 - PipeInputStream in Process (java.lang) // per skip() invocation buffer byte[2048]
 - CheckedInputStream (java.util.zip)     // per skip() invocation buffer byte[512]
 - InflaterInputStream (java.util.zip)    // per skip() invocation buffer byte[512]
 - AppInputStream in SSLSocketImpl (sun.security.ssl) // per skip() invocation buffer byte[256]
 - DeflaterInputStream (java.util.zip)   //  cached  skip buffer, byte[512], allocated on demand
 - ZipInputStream (java.util.zip)       //   preallocated skip buffer byte[512]
 - HttpInputStream in HttpURLConnection (sun.net.www.protocol.http) //  cached  skip buffer, byte[8096], allocated on demand

It would be better to clean all skip implementations for the latter category and make it consistent. Now it's totally a mess. All possible strategies were implemented.

Now let's consider classes which uses InputStream.skip() implementation (21 classes):

4) skip() is not implemented, when trivial implementation is possible (4 classes):
 - EmptyInputStream (sun.net.www.protocol.http)
 - NullInputStream in ProcessBuilder (java.lang)
 - ObjectInputStream (java.io)
 - extObjectInputStream (javax.crypto)

5) skip() is not implemented, when not-so-trivial implementation is possible (9 classes):
 - Anonymous in getInputStream() in NioSocketImpl (sun.nio.ch)  
   Notes: temp direct buffer is used for reading, it's possible to implement skip over the direct buffer, save allocation + no copying from direct buffer to byte[]
 - Anonymous in newInputStream() in Channels (java.nio.channels)
   Notes: temp direct buffer is used for reading, it's possible to implement skip over the direct buffer, save allocation + no copying from direct buffer to byte[]
 - ChunkedInputStream (sun.net.www.http)
   Notes: skip() maybe implemented with the existing internal buffer
 - DecInputStream in Base64 (java.util)   
 - ErrorStream in HttpURLConnection (sun.net.www.protocol.http)
   Notes: skip (but easily can be implemented with internal buffer + delegation to tail stream)
 - PipedInputStream (java.io)
   Notes: skip() may be implemented with the existing internal buffer
 - SequenceInputStream (java.io)   
   Notes: skip() maybe implemented with delegation
 - SocketInputStream (sun.nio.ch)   
   Notes: temp direct buffer is used for reading, it's possible to implement skip over the direct buffer, save allocation + no copying from direct buffer to byte[]
 - SocketInputStream in Socket (java.net)
   Notes: skip() maybe implemented with delegation

And the last category:

6) skip() is not implemented, and skip buffer is unavoidable (8 classes):
  - VerifierStream in JarVerifier (java.util.jar)
  - DigestInputStream (java.security)
  - HttpCaptureInputStream (sun.net.www.http)  
  - InflaterInputStream (java.util.zip)
  - GZIPInputStream (java.util.zip)
  - ZipFileInflaterInputStream in ZipFile (java.util.zip)
  - ZipInputStream (java.util.zip)
  - JarInputStream (java.util.jar)

Only categories 3 & 6 need skip buffers (15 classes). In all other cases, we don't need skip buffer and if we will clean all InputStream subclasses it gives much more value than the original PR.

As about 3d party InputStream subclasses - let the owner takes care of the implementation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From skuksenko at openjdk.java.net  Sun May 29 18:26:49 2022
From: skuksenko at openjdk.java.net (Sergey Kuksenko)
Date: Sun, 29 May 2022 18:26:49 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v15]
In-Reply-To: <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
Message-ID: <aqT-j9RDOy7-lOjZB3ScTZ7stT2AlTKXFFI2jQByXE8=.4667fe33-0ed1-4cb4-a28b-ece5c80aa832@github.com>

On Tue, 24 May 2022 20:40:51 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   invert if; refine javadoc.

Another InputStreams cleaning direction.

Many InputStream subclasses have read(byte[],...) as a primary implementation. Somehow they should implement 1-byte reading (read()) via array reading. All imaginable strategies are used:
- allocate byte[1] per read() invocation
- cache byte[1] preallocated
- cache byte[1], allocation on demand
- share 1-byte read buffer and skip buffer, as preallocating and allocating on demand.
- etc

So cleaning and making consistent all 1-byte read implementations - also may be valuable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Sun May 29 23:34:48 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Sun, 29 May 2022 23:34:48 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v15]
In-Reply-To: <aqT-j9RDOy7-lOjZB3ScTZ7stT2AlTKXFFI2jQByXE8=.4667fe33-0ed1-4cb4-a28b-ece5c80aa832@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
 <aqT-j9RDOy7-lOjZB3ScTZ7stT2AlTKXFFI2jQByXE8=.4667fe33-0ed1-4cb4-a28b-ece5c80aa832@github.com>
Message-ID: <Qb9E5JdqpTF_wDuyB4gkba35kJqH1HkJSRYGE1U5qKw=.d57b4a51-0262-4bbe-a574-6f870ceacd69@github.com>

On Sun, 29 May 2022 18:23:03 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   invert if; refine javadoc.
>
> Another InputStreams cleaning direction.
> 
> Many InputStream subclasses have read(byte[],...) as a primary implementation. Somehow they should implement 1-byte reading (read()) via array reading. All imaginable strategies are used:
> - allocate byte[1] per read() invocation
> - cache byte[1] preallocated
> - cache byte[1], allocation on demand
> - share 1-byte read buffer and skip buffer, as preallocating and allocating on demand.
> - etc
> 
> So cleaning and making consistent all 1-byte read implementations - also may be valuable.

@kuksenko good suggestions. I would have a try when have time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From duke at openjdk.java.net  Mon May 30 00:10:50 2022
From: duke at openjdk.java.net (Tim Prinzing)
Date: Mon, 30 May 2022 00:10:50 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v3]
In-Reply-To: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
Message-ID: <EHoFyUMigGVOCBpQh4nyb3CVm-iRxiNquJGTkfJ0ei4=.fd2c8d1a-235b-44d0-a0a2-6027230a7964@github.com>

> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  problem with iostream on Windows, use printf

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8934/files
  - new: https://git.openjdk.java.net/jdk/pull/8934/files/a54aa747..f1406a45

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8934&range=01-02

  Stats: 14 lines in 2 files changed: 8 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8934.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8934/head:pull/8934

PR: https://git.openjdk.java.net/jdk/pull/8934

From xgong at openjdk.java.net  Mon May 30 01:20:51 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 30 May 2022 01:20:51 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v2]
In-Reply-To: <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>
Message-ID: <uJLpkCZdNUpfugjsnuUpiXQp29CS64WvqX98HsMMW-M=.9994429f-9e95-4cd9-b20f-7501cb647af1@github.com>

On Fri, 13 May 2022 01:35:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Checking whether the indexes of masked lanes are inside of the valid memory boundary is necessary for masked vector memory access. However, this could be saved if the given offset is inside of the vector range that could make sure no IOOBE (IndexOutOfBoundaryException) happens. The masked load APIs have saved this kind of check for common cases. And this patch did the similar optimization for the masked vector store.
>> 
>> The performance for the new added store masked benchmarks improves about `1.83x ~ 2.62x` on a x86 system:
>> 
>> Benchmark                                   Before    After     Gain Units
>> StoreMaskedBenchmark.byteStoreArrayMask   12757.936 23291.118  1.826 ops/ms
>> StoreMaskedBenchmark.doubleStoreArrayMask  1520.932  3921.616  2.578 ops/ms
>> StoreMaskedBenchmark.floatStoreArrayMask   2713.031  7122.535  2.625 ops/ms
>> StoreMaskedBenchmark.intStoreArrayMask     4113.772  8220.206  1.998 ops/ms
>> StoreMaskedBenchmark.longStoreArrayMask    1993.986  4874.148  2.444 ops/ms
>> StoreMaskedBenchmark.shortStoreArrayMask   8543.593 17821.086  2.086 ops/ms
>> 
>> Similar performane gain can also be observed on ARM hardware.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap the offset check into a static method

@PaulSandoz, could you please help to check whether the current version is ok for you? Thanks so much!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From alanb at openjdk.java.net  Mon May 30 05:32:54 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 May 2022 05:32:54 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v15]
In-Reply-To: <RKHI2lmf0kIgp6Ml9JdkusKVWbfTW8sD_j6aTiBQDco=.f4086d6f-7325-4237-8739-d19eb5bde0a4@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
 <RKHI2lmf0kIgp6Ml9JdkusKVWbfTW8sD_j6aTiBQDco=.f4086d6f-7325-4237-8739-d19eb5bde0a4@github.com>
Message-ID: <8xCLMogXXW-kf987ixPbalJMkOK5K-yNtWmJex55TZU=.435ebbf0-41da-4e5b-8b5b-2ab5a064ec27@github.com>

On Sun, 29 May 2022 18:15:52 GMT, Sergey Kuksenko <skuksenko at openjdk.org> wrote:

> 5. skip() is not implemented, when not-so-trivial implementation is possible (9 classes):

For the low-level streams (e.g. connected to socket) then it would be common to see them wrapped by buffered streams. So it might not be worth doing anything there.

However, I think your suggestion to change the no-arg read/write be non-abstract is interesting as it's always a pain to have to implement that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From alanb at openjdk.java.net  Mon May 30 05:33:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 May 2022 05:33:40 GMT
Subject: RFR: 8287363: null pointer should use NULL instead of 0
In-Reply-To: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>
References: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>
Message-ID: <D9ryfr0EU1MfVsV4vbQtcYKkj8uAwNZXmU7Od7s6Uhc=.b3036912-420c-4611-9d68-830d3d8d43c8@github.com>

On Sat, 28 May 2022 03:31:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We found using `0` as `NULL` in java_md_common.c . `0` is not a pointer, so we should use `NULL` where we want to handle it.
> 
> https://github.com/openjdk/jdk/pull/8646#discussion_r882294076
> 
> Also I found using `0` as NUL char in java_md_common.c , so I replaced it to `\0` in this PR.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8931

From alanb at openjdk.java.net  Mon May 30 05:40:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 May 2022 05:40:40 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v3]
In-Reply-To: <EHoFyUMigGVOCBpQh4nyb3CVm-iRxiNquJGTkfJ0ei4=.fd2c8d1a-235b-44d0-a0a2-6027230a7964@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <EHoFyUMigGVOCBpQh4nyb3CVm-iRxiNquJGTkfJ0ei4=.fd2c8d1a-235b-44d0-a0a2-6027230a7964@github.com>
Message-ID: <l1sQtEvlaQYid5hChUR-LYIUQ1MmUReWBPcA-c3dmEY=.c23da7dd-7b17-4c42-b0d2-66bcbfe2ac48@github.com>

On Mon, 30 May 2022 00:10:50 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   problem with iostream on Windows, use printf

I don't think jdk/nullCaller is right location for this. Maybe jni/nullCaller could work. You'll probably need to add the location to an appropriate group/tier in test/jdk/TEST.groups, otherwise it won't be run.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8934

From iklam at openjdk.java.net  Mon May 30 06:19:42 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 30 May 2022 06:19:42 GMT
Subject: RFR: 8287073: NPE from CgroupV2Subsystem.getInstance() [v3]
In-Reply-To: <9hRC8HIFXnO9nVT7BXFnNBo_ZM5nAvIgxreAgQU0p1Q=.de49b0e4-9107-4ae7-84f7-2a805c19ad68@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
 <9hRC8HIFXnO9nVT7BXFnNBo_ZM5nAvIgxreAgQU0p1Q=.de49b0e4-9107-4ae7-84f7-2a805c19ad68@github.com>
Message-ID: <mqqqkF8_n3inZoup0RRe7ASWNtlafZoYqoyMVdDPpVk=.6de435d4-f313-41a4-8093-8e337d61bed2@github.com>

On Thu, 26 May 2022 16:04:17 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. 
>> 
>> It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made requested changes

I tested the patch in our CI pipeline. All container tests passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From mkartashev at openjdk.java.net  Mon May 30 06:22:33 2022
From: mkartashev at openjdk.java.net (Maxim Kartashev)
Date: Mon, 30 May 2022 06:22:33 GMT
Subject: Integrated: 8287073: NPE from CgroupV2Subsystem.getInstance()
In-Reply-To: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
References: <L1sE3JD1LuKmWQxOTIbLZiiwysvXQLvwdL2U0ZnzujQ=.1f6f7a18-4c99-4253-85b3-e5b3ef75e823@github.com>
Message-ID: <Ve3wLIzxZdObu2spIp0X1fuw4aZJnkDGrgeK5m3Blg8=.070c7291-3dcb-4461-a2ce-7ce18d71b9d2@github.com>

On Fri, 20 May 2022 08:34:58 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Following the logic from the comment directly above the changed line, since it doesn't matter which controller we pick, pick any available controller instead of the one called "memory" specifically. This way we are guarded against getting `null` as `anyController`, which is being immediately passed down to `CgroupV2Subsystem.getInstance()` that is unprepared to accept `null` values. 
> 
> It is also worth noting that the previous checks (such as that at line 89) make sure that there exist at least one controller in the map.

This pull request has now been integrated.

Changeset: 744b822a
Author:    Maxim Kartashev <mkartashev at openjdk.org>
Committer: Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/744b822ab194a0f7ef4e7a4053be32c6a0889efc
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8287073: NPE from CgroupV2Subsystem.getInstance()

Reviewed-by: vkempik, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/8803

From ysuenaga at openjdk.java.net  Mon May 30 07:05:45 2022
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 30 May 2022 07:05:45 GMT
Subject: Integrated: 8287363: null pointer should use NULL instead of 0
In-Reply-To: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>
References: <JKypfkRnI6dGV454cCENNItSKmm5euYTaam5ElYv7Kc=.c42938a3-ffed-4fc9-80d1-660d5dd96e57@github.com>
Message-ID: <tTmmJ_NPOZXztUqsVFjqwPCOZ3uhef_TQuRHbHsvIIU=.4d5d0dcd-067e-47bf-8512-93f750aae192@github.com>

On Sat, 28 May 2022 03:31:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We found using `0` as `NULL` in java_md_common.c . `0` is not a pointer, so we should use `NULL` where we want to handle it.
> 
> https://github.com/openjdk/jdk/pull/8646#discussion_r882294076
> 
> Also I found using `0` as NUL char in java_md_common.c , so I replaced it to `\0` in this PR.

This pull request has now been integrated.

Changeset: a27ba1a3
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a27ba1a3db5f0b4eb75b6cca94f33398e7b695cc
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8287363: null pointer should use NULL instead of 0

Reviewed-by: kbarrett, stuefe, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8931

From duke at openjdk.java.net  Mon May 30 08:59:41 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 30 May 2022 08:59:41 GMT
Subject: RFR: 8287497: Use String.contains() instead of String.indexOf() in
 java.naming
In-Reply-To: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
References: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
Message-ID: <DZ-sqc34G2MsD6bUrTClFQcIEq0hqe90ymD7GhFmo6g=.9c557306-de63-4170-841a-147bb8ea0cab@github.com>

On Sun, 29 May 2022 14:00:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `String.contains` was introduced in Java 5.
> Some code in java.naming still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

_(not a reviewer)_
Provided `indexOf() != -1` and `indexOf() >= 0` are equivalent (which should indeed be the case, according to the Javadoc), the changes look good

-------------

PR: https://git.openjdk.java.net/jdk/pull/8938

From duke at openjdk.java.net  Mon May 30 09:18:46 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Mon, 30 May 2022 09:18:46 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v15]
In-Reply-To: <8xCLMogXXW-kf987ixPbalJMkOK5K-yNtWmJex55TZU=.435ebbf0-41da-4e5b-8b5b-2ab5a064ec27@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
 <RKHI2lmf0kIgp6Ml9JdkusKVWbfTW8sD_j6aTiBQDco=.f4086d6f-7325-4237-8739-d19eb5bde0a4@github.com>
 <8xCLMogXXW-kf987ixPbalJMkOK5K-yNtWmJex55TZU=.435ebbf0-41da-4e5b-8b5b-2ab5a064ec27@github.com>
Message-ID: <mgdYhpwgYSOH_9ugG_Y3KDRSL4T0RXWQd8horJdB2Sc=.2135c267-5544-4cb8-9180-ed15abd155b8@github.com>

On Mon, 30 May 2022 05:29:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> However, I think your suggestion to change the no-arg read/write be non-abstract is interesting as it's always a pain to have to implement that.

@AlanBateman  this need a csr IMO?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From ihse at openjdk.java.net  Mon May 30 09:26:31 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 30 May 2022 09:26:31 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v3]
In-Reply-To: <EHoFyUMigGVOCBpQh4nyb3CVm-iRxiNquJGTkfJ0ei4=.fd2c8d1a-235b-44d0-a0a2-6027230a7964@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <EHoFyUMigGVOCBpQh4nyb3CVm-iRxiNquJGTkfJ0ei4=.fd2c8d1a-235b-44d0-a0a2-6027230a7964@github.com>
Message-ID: <G9wsfmBpR2UOirou0Dz9ljxd_w2v2r4uQCTkXEkBI8s=.fe73088c-20c0-4e72-bb9b-4e3f59ca4f60@github.com>

On Mon, 30 May 2022 00:10:50 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   problem with iostream on Windows, use printf

Build changes look good.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8934

From alanb at openjdk.java.net  Mon May 30 10:47:31 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 May 2022 10:47:31 GMT
Subject: RFR: 8284638: store skip buffers in InputStream Object [v15]
In-Reply-To: <8xCLMogXXW-kf987ixPbalJMkOK5K-yNtWmJex55TZU=.435ebbf0-41da-4e5b-8b5b-2ab5a064ec27@github.com>
References: <wt_n9E3sZ0Zl3N9MkpJYxd_wmKmN8YOKyXcN1xA6i8s=.5a85d55d-6773-41d5-83ce-0f54d662dbc6@github.com>
 <rNPKxMdsRi8V5BdJ-hvDgLnllWCrUNBKJIbt9yRlWLw=.14643ad3-58ee-4657-b0a7-5d46f7194c2c@github.com>
 <RKHI2lmf0kIgp6Ml9JdkusKVWbfTW8sD_j6aTiBQDco=.f4086d6f-7325-4237-8739-d19eb5bde0a4@github.com>
 <8xCLMogXXW-kf987ixPbalJMkOK5K-yNtWmJex55TZU=.435ebbf0-41da-4e5b-8b5b-2ab5a064ec27@github.com>
Message-ID: <u31l4mpUmmlqgKTzxb1M-V7vR3QQRCcvf8f416QXUA4=.0d990828-c5af-48c8-8e82-e0ecdc117142@github.com>

On Mon, 30 May 2022 05:29:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> More practically.
>> This PR has a noticeable negative effect - it increases the size of InputStream objects. Moreover, it increases the size of InputStream subclasses which has own skip() implementation and don't need this superclass modification.
>> 
>> Let's look into InputStream subclasses.
>> I've checked 51 InputStream from classlib. 30 of them either have their own skip() implementation or use super.skip() other than from InputStream. This PR is definitely harmful to these 30 classes. These 30 classes can be divided into the following categories:
>> 
>> 1) Clean non-allocating skip() implementation (22 classes):
>>  - BufferedInputStream (java.io) 
>>  - ByteArrayInputStream (java.io)
>>  - FileInputStream (java.io) 
>>  - FilterInputStream (java.io)
>>  - PeekInputStream in ObjectInputStream (java.io)
>>  - BlockDataInputStream in ObjectInputStream (java.io) 
>>  - PushbackInputStream (java.io) 
>>  - FastInputStream in Manifest (java.util.jar)
>>  - ZipFileInputStream in ZipFile (java.util.zip)
>>  - CipherInputStream (javax.crypto)
>>  - MeteredStream (sun.net.www)
>>  - Anonymous in nullInputStream() in InputStream (java.io)
>>  - DataInputStream (java.io)
>>  - Anonymous in readTrailer() in GZIPInputStream (java.util.zip)
>>  - FtpInputStream in FtpURLConnection (sun.net.www.protocol.ftp)
>>  - JarURLInputStream in JarURLConnection (sun.net.www.protocol.jar)
>>  - PlainTextInputStream (sun.net.www.content.text)
>>  - PushbackInputStream (java.io)
>>  - TelnetInputStream (sun.net)
>>  - UnclosableInputStream in FileInputStreamPool (sun.security.provider)
>>  - MeteredStream (sun.net.www)
>>  - KeepAliveStream (sun.net.www.http)
>> 
>> 2) Partially clean skip() implementation (1 class):
>>  - ChannelInputStream (sun.nio.ch)
>>    Note: clean skip impl when using SeekableByteChannel (most usages) otherwise super.skip() is used, and it may be easily rewritten using the existing internal buffer.
>> 
>> 3) Unavoidable skip buffers (7 classes):
>>  - PipeInputStream in Process (java.lang) // per skip() invocation buffer byte[2048]
>>  - CheckedInputStream (java.util.zip)     // per skip() invocation buffer byte[512]
>>  - InflaterInputStream (java.util.zip)    // per skip() invocation buffer byte[512]
>>  - AppInputStream in SSLSocketImpl (sun.security.ssl) // per skip() invocation buffer byte[256]
>>  - DeflaterInputStream (java.util.zip)   //  cached  skip buffer, byte[512], allocated on demand
>>  - ZipInputStream (java.util.zip)       //   preallocated skip buffer byte[512]
>>  - HttpInputStream in HttpURLConnection (sun.net.www.protocol.http) //  cached  skip buffer, byte[8096], allocated on demand
>> 
>> It would be better to clean all skip implementations for the latter category and make it consistent. Now it's totally a mess. All possible strategies were implemented.
>> 
>> Now let's consider classes which uses InputStream.skip() implementation (21 classes):
>> 
>> 4) skip() is not implemented, when trivial implementation is possible (4 classes):
>>  - EmptyInputStream (sun.net.www.protocol.http)
>>  - NullInputStream in ProcessBuilder (java.lang)
>>  - ObjectInputStream (java.io)
>>  - extObjectInputStream (javax.crypto)
>> 
>> 5) skip() is not implemented, when not-so-trivial implementation is possible (9 classes):
>>  - Anonymous in getInputStream() in NioSocketImpl (sun.nio.ch)  
>>    Notes: temp direct buffer is used for reading, it's possible to implement skip over the direct buffer, save allocation + no copying from direct buffer to byte[]
>>  - Anonymous in newInputStream() in Channels (java.nio.channels)
>>    Notes: temp direct buffer is used for reading, it's possible to implement skip over the direct buffer, save allocation + no copying from direct buffer to byte[]
>>  - ChunkedInputStream (sun.net.www.http)
>>    Notes: skip() maybe implemented with the existing internal buffer
>>  - DecInputStream in Base64 (java.util)   
>>  - ErrorStream in HttpURLConnection (sun.net.www.protocol.http)
>>    Notes: skip (but easily can be implemented with internal buffer + delegation to tail stream)
>>  - PipedInputStream (java.io)
>>    Notes: skip() may be implemented with the existing internal buffer
>>  - SequenceInputStream (java.io)   
>>    Notes: skip() maybe implemented with delegation
>>  - SocketInputStream (sun.nio.ch)   
>>    Notes: temp direct buffer is used for reading, it's possible to implement skip over the direct buffer, save allocation + no copying from direct buffer to byte[]
>>  - SocketInputStream in Socket (java.net)
>>    Notes: skip() maybe implemented with delegation
>> 
>> And the last category:
>> 
>> 6) skip() is not implemented, and skip buffer is unavoidable (8 classes):
>>   - VerifierStream in JarVerifier (java.util.jar)
>>   - DigestInputStream (java.security)
>>   - HttpCaptureInputStream (sun.net.www.http)  
>>   - InflaterInputStream (java.util.zip)
>>   - GZIPInputStream (java.util.zip)
>>   - ZipFileInflaterInputStream in ZipFile (java.util.zip)
>>   - ZipInputStream (java.util.zip)
>>   - JarInputStream (java.util.jar)
>> 
>> Only categories 3 & 6 need skip buffers (15 classes). In all other cases, we don't need skip buffer and if we will clean all InputStream subclasses it gives much more value than the original PR.
>> 
>> As about 3d party InputStream subclasses - let the owner takes care of the implementation.
>
>> 5. skip() is not implemented, when not-so-trivial implementation is possible (9 classes):
> 
> For the low-level streams (e.g. connected to socket) then it would be common to see them wrapped by buffered streams. So it might not be worth doing anything there.
> 
> However, I think your suggestion to change the no-arg read/write be non-abstract is interesting as it's always a pain to have to implement that.

> @AlanBateman this need a csr IMO?

Changing InputStream.read to be non-abstract would be an API change and so would require a CSR. I think try it first, the main thing is to satisfy yourself that there aren't any compatibility issues, e.g. when InputStream is extended by an abstract class with a non-abstract read method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5872

From aefimov at openjdk.java.net  Mon May 30 12:58:34 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 30 May 2022 12:58:34 GMT
Subject: RFR: 8287497: Use String.contains() instead of String.indexOf() in
 java.naming
In-Reply-To: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
References: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
Message-ID: <PARigyVAsmuoViS8h7yChk5aeBaRaUleV7nkAWs8Lo0=.a683bd67-8dee-4a4f-94ff-d542e3b05a73@github.com>

On Sun, 29 May 2022 14:00:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `String.contains` was introduced in Java 5.
> Some code in java.naming still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

The change looks good to me.
I've checked the fix with our CI system and no `java.naming` failures have been discovered.

-------------

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8938

From redestad at openjdk.java.net  Mon May 30 13:18:15 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 30 May 2022 13:18:15 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches
Message-ID: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>

When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 

Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):

| Build      |    # classes    |   Runtime   |
| ----------- | ----------------- |  --------------- |
| Baseline |     31119       |     2.942s     |
| Patch      |     16208       |     1.958s     |

An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:

Baseline:

Benchmark                                                      Mode  Cnt     Score      Error   Units
SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op

This patch:

Benchmark                                                      Mode  Cnt     Score      Error   Units
SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

-------------

Commit messages:
 - Revert change to HelloClasslist (doesn't affect generation)
 - Reduce allocation adding in mixers by extracting constant arg lists and caching double arg mixers
 - De-CHM the prepender and mixer caches
 - Reduce allocations: Extract constant argument lists, cache base form for two-arg prependers
 - Refactor, reduce allocations
 - Merge branch 'master' into scf_chunked
 - Improve chunking further
 - Fix mis-merged change
 - Experiment: Chunk prependers and mixers to reduce number of rebinds and generated LF classes

Changes: https://git.openjdk.java.net/jdk/pull/8855/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8855&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287522
  Stats: 390 lines in 2 files changed: 232 ins; 99 del; 59 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8855.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8855/head:pull/8855

PR: https://git.openjdk.java.net/jdk/pull/8855

From jlaskey at openjdk.java.net  Mon May 30 13:18:15 2022
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 30 May 2022 13:18:15 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches
In-Reply-To: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
Message-ID: <SMMXxTAOdUX8717Lh7MROC0at0isFz4rbAEWUL7MVQM=.aaeeee7b-12ac-4f55-b6eb-e8d2dfaaa3b7@github.com>

On Mon, 23 May 2022 20:03:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
> 
> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
> 
> | Build      |    # classes    |   Runtime   |
> | ----------- | ----------------- |  --------------- |
> | Baseline |     31119       |     2.942s     |
> | Patch      |     16208       |     1.958s     |
> 
> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
> 
> This patch:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

LGTM

-------------

Marked as reviewed by jlaskey (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8855

From redestad at openjdk.java.net  Mon May 30 13:18:15 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 30 May 2022 13:18:15 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches
In-Reply-To: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
Message-ID: <Xp9ezZZjszRCKQJbywgiCR38K75Fn0dHunqkub3zOGE=.5c601f21-3c8a-4113-89b2-4e9793575ff5@github.com>

On Mon, 23 May 2022 20:03:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
> 
> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
> 
> | Build      |    # classes    |   Runtime   |
> | ----------- | ----------------- |  --------------- |
> | Baseline |     31119       |     2.942s     |
> | Patch      |     16208       |     1.958s     |
> 
> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
> 
> This patch:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

Before moving forward with this I've been looking at slightly more expensive bootstrapping of already known shapes. On one such bootstrap microbenchmark, `StringConcatFactoryBootstraps` this patch would cause a ~25% slowdown (and a 33% increase in allocations). Not too concerning, but since the purpose of this patch is to reduce String concat bootstrapping overhead it would be nice to not trade that for a localized regression.

First improvement was to pack `TransformKey`s better: #8881 - which helps both variants, but doesn't really narrow the gap.

We can improve further outside of `StringConcatFactory` to prepare for this RFE by reducing the number List-to-array and array-to-List conversions in `MethodHandles.dropArguments` (-280b/op). Another candidate is to turn `LambdaFormEditor` either into a static utility or it into `LamdaForm` proper (TBD if this is worthwhile; they're tightly coupled, and all state maintained by `LambdaFormEditor` lives in `LambdaForm`).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8855

From duke at openjdk.java.net  Mon May 30 15:21:29 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Mon, 30 May 2022 15:21:29 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v2]
In-Reply-To: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
Message-ID: <3Aj7iQ9CH4wSg_1bf_8gX7MPMrIhzHi92SQED8UInnQ=.6ea9fc33-1d8c-4bd1-9399-c07330326fa4@github.com>

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:

  8285838: Revised changes for Custom TZ DST test fixes.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/dcf762a5..41e75494

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=00-01

  Stats: 94 lines in 3 files changed: 20 ins; 62 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8661/head:pull/8661

PR: https://git.openjdk.java.net/jdk/pull/8661

From duke at openjdk.java.net  Mon May 30 15:21:30 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Mon, 30 May 2022 15:21:30 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v2]
In-Reply-To: <XzQM021bjWZolW_iQHJH5xDbIH3XKu1rvmlehAeOQWA=.48cb1180-d888-4e20-911f-2f23f544f0c7@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <XzQM021bjWZolW_iQHJH5xDbIH3XKu1rvmlehAeOQWA=.48cb1180-d888-4e20-911f-2f23f544f0c7@github.com>
Message-ID: <XAStBBbSzZwFQObT_jGezJ1342BC1uqH8a9ZGrz7N6g=.bf082322-a692-41b8-8b48-eda1b8f194ef@github.com>

On Tue, 17 May 2022 20:19:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285838: Revised changes for Custom TZ DST test fixes.
>
> src/java.base/unix/native/libjava/TimeZone_md.c line 609:
> 
>> 607:     }
>> 608: 
>> 609:     offset = (gmt.tm_hour - localtm.tm_hour)*3600 + (gmt.tm_min - localtm.tm_min)*60;
> 
> Since it is not using `timezone` anymore, we can reverse the subtraction, i.e., `localtime` - `gmtime` so that the weird sign switch below can be eliminated.

I've reversed it and reverted the weird sign switching below this code snippet.

> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2001, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> This is a new test case, the year should be only 2022.

Thanks, corrected this in the following commit

> test/jdk/java/util/TimeZone/runCustomTzIDCheckDST.sh line 1:
> 
>> 1: #
> 
> I'd change this script into a java test case (using `.sh` is not recommended). In fact, this causes a failure invoking `javac` with `-Xmx768m` (from TESTVMOPTS)
> There are libraries under `jdk/test/lib/` for building test jvm process and tools.

I did away with this .sh script and combined the shell script and java test into one. Initially the only purpose of this shell script was in order to set up the environment variable for the proceeding test. However, I learnt that all this could be done within java, and I consolidated both the files into one test now.

> test/jdk/java/util/TimeZone/runCustomTzIDCheckDST.sh line 40:
> 
>> 38: 
>> 39: OS=`uname -s`
>> 40: case "$OS" in 
> 
> In case other than Linux/AIX, it would be helpful to emit some message that the test is ignored.

All moved to one java test now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From duke at openjdk.java.net  Mon May 30 15:32:36 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Mon, 30 May 2022 15:32:36 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v3]
In-Reply-To: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
Message-ID: <av9Tqhz5Qwin4AEXaMcjDjOmi_L1ceTPtFycw1AbX4o=.785d163b-586d-482c-8faf-24be93b27ff0@github.com>

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
 - 8285838: Revised changes for Custom TZ DST test fixes.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/41e75494..b80af8bf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8661/head:pull/8661

PR: https://git.openjdk.java.net/jdk/pull/8661

From rriggs at openjdk.java.net  Mon May 30 15:38:53 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 30 May 2022 15:38:53 GMT
Subject: RFR: 8287497: Use String.contains() instead of String.indexOf() in
 java.naming
In-Reply-To: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
References: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
Message-ID: <gK06opGEt4UL0lFx9xcoNPHm9bilFY4o1SDD0HBv_94=.3a052a12-ab04-477a-a68c-f40ecaf7dc77@github.com>

On Sun, 29 May 2022 14:00:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `String.contains` was introduced in Java 5.
> Some code in java.naming still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8938

From duke at openjdk.java.net  Mon May 30 15:40:37 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Mon, 30 May 2022 15:40:37 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v4]
In-Reply-To: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
Message-ID: <UCmcIC38gTHOC4h24nU36xV973FAPzOYVeN5UEKGt7E=.80b8b023-b3cd-4fa6-8833-5c12b59e45d9@github.com>

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
 - Merge branch '8285838' of github.com:Deigue/jdk into 8285838

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/b80af8bf..d7831659

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8661/head:pull/8661

PR: https://git.openjdk.java.net/jdk/pull/8661

From mcimadamore at openjdk.java.net  Mon May 30 15:43:48 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 30 May 2022 15:43:48 GMT
Subject: Integrated: 8287430  MemorySessionImpl::addOrCleanupIfFail does not
 rethrow exceptions
In-Reply-To: <36Nx6DXetJleJasUGEQ8S_a3p2nbf2FhP5AqcFLUskk=.5c337e5e-947f-425a-a8f4-818b78f13cf8@github.com>
References: <36Nx6DXetJleJasUGEQ8S_a3p2nbf2FhP5AqcFLUskk=.5c337e5e-947f-425a-a8f4-818b78f13cf8@github.com>
Message-ID: <jQsBL6qcc-xXOIWchS5giU9w7vn8kN1bmUDxeXgec0o=.71fbea34-42f0-45eb-89b2-99cdf53c9068@github.com>

On Fri, 27 May 2022 10:29:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fix a missing rethrow in `MemorySessionImpl::addOrCleanupIfFail`. As noted in the JBS issue, this bug does not affect correctness, but it delays error reporting.
> 
> Writing a test for this is nearly impossible, given that (a) a memory resource created against a closed session would be inaccessible by clients (because the session is closed!), and (b) because of the narrow window in which the problem might manifest (for this problem to occur, a session state change would have to occur between the first state check and when the cleanup action list is updated).

This pull request has now been integrated.

Changeset: 0c420e03
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0c420e03ae24144a8146edb39f546841da33e381
Stats:     9 lines in 1 file changed: 3 ins; 0 del; 6 mod

8287430: MemorySessionImpl::addOrCleanupIfFail does not rethrow exceptions

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.java.net/jdk/pull/8917

From alanb at openjdk.java.net  Mon May 30 16:52:02 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 May 2022 16:52:02 GMT
Subject: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
 [v4]
In-Reply-To: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
References: <HDe3nmj_aNisyJBQCi3CamYCtu378WzjeRBbX4M6xJs=.35a3dbe4-7c50-4a23-98c8-5dc1932db85f@github.com>
Message-ID: <aglkkh3Z3Kpahy-sbIC91RX5W9b4KPlHmEzV8BDOKnw=.0ecd3003-e940-4e13-b3f1-d04516828632@github.com>

> This is the implementation of JEP 428: Structured Concurrency (Incubator).
> 
> This is a non-final API that provides a gentle on-ramp to structure a task as a family of concurrent subtasks, and to coordinate the subtasks as a unit.

Alan Bateman 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 10 additional commits since the last revision:

 - Fix typo in javadoc
 - Merge
 - Javadoc updates, add to jdk_loom test group
 - Add statement to close about thread termination
 - Use {@code ...}, replace task->subtask, fix typos, add jls ref
 - Merge
 - @ignore StructuredThreadDumpTest until test infra in place
 - Refresh
 - Merge
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8787/files
  - new: https://git.openjdk.java.net/jdk/pull/8787/files/4fc454a9..d11b24bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8787&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8787&range=02-03

  Stats: 33428 lines in 507 files changed: 6180 ins; 25559 del; 1689 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8787.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8787/head:pull/8787

PR: https://git.openjdk.java.net/jdk/pull/8787

From akozlov at azul.com  Mon May 30 14:17:34 2022
From: akozlov at azul.com (Anton Kozlov)
Date: Mon, 30 May 2022 17:17:34 +0300
Subject: [crac] RFR: Ensure empty Reference Handler and Cleaners queues
In-Reply-To: <beacef34-6df8-0265-0589-728a3fcde1df@azul.com>
References: <UyPQr_UceyLBJw5NkFdOuJzhItXM8czwutv1KlZM06o=.24fe3b1e-eb19-458d-a8b7-0cea21f87dfa@github.com>
 <cfe284da-5ca2-c2c9-68a7-f8e436c59ea3@azul.com>
 <1c2136a0-90c2-cabc-a948-bc4a02f1533b@oracle.com>
 <beacef34-6df8-0265-0589-728a3fcde1df@azul.com>
Message-ID: <4990dc41-f466-007b-6128-d5b9d410c553@azul.com>

Could you please look at the updated version at [0]?

The new API for ReferenceQueue still targets the problem of
synchronizing Reference handling with CRaC.  An example of that is a
java object that becomes unreachable just before the checkpoint, and an
associated Reference needs to be processed to release some native
resource.  Creating an image of the VM with that native resource linked
is both unsafe (the native resource may not exist at the restore -- CRaC
VM does its best to prevent successful checkpoint in this case) and
inefficient, as every restored instance will perform the same processing
of the same Reference that was captured by the image.  So we need to
ensure Reference processing is complete.

For the processing done by a thread (or a set of threads), the change
provides an updated API to await the set of threads blocked on the Queue
awaiting references.  This ensures that threads are done processing
References from that Queue.

> > Once the method returns then there is no guarantee that the number
> > of waiters hasn't changed, but I think you know that
>
> I hoped to guarantee all Queues are empty by waiting a sufficient
> number of waiters for each Queue, in the order of Queues passing
> References between each other (for a single thread). But now even
> there, I see handling of a Reference later in the order may make
> another one pending, filling up a Queue that was supposed to be empty.
> For a strong guarantee that all Queues are empty, some sort of
> iteration may be required, that will check no Queue had a new
> reference since the last check.

Processing of a single Reference may generate an arbitrary number of
more enqueued References. More formally, ReferenceQueues and their
processors form a directed graph, in which nodes are Queues and edges
are relation "handling of a Reference from the source may enqueue
another Reference into destination". Edges are defined by the code of
processing and not data. The graph can be of the arbitrary form, e.g.
there can be cycles, so Reference processing does not need even to
converge.

So the only reasonable way to get reference processing quiescent is to
ensure References for each Queue are processed (by calling the new API),
in the order of Queues may get References.

> I think a public API is needed as users may have the same problem as
> we do. But the current code does not support this (we need to allow
> user code after JDK Queues are emptied).

The API now fully supports calling from the user code.  Each invocation
of the new API ensures all unreachable objects are discovered and pushed
to a Queue before the Queue is checked for pending references and the
number of waiting threads.

> > At a high level it should be okay to provide a JDK-internal way to
> > await quiescent. You've added it as a public API which might be okay
> > for the current exploration but I don't think it would be exposed in
> > its current form.

The new ReferenceQueue API is moved into jdk.crac.* package, to avoid
polluting Java API of CRaC EA builds that are based on JDK 17 for now.

[0] https://github.com/openjdk/crac/pull/22
[1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/WeakHashMap.java#L361

Thanks,
Anton


From redestad at openjdk.java.net  Mon May 30 20:23:40 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 30 May 2022 20:23:40 GMT
Subject: RFR: 8287522: StringConcatFactory: Add in prependers and mixers in
 batches [v2]
In-Reply-To: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
References: <7YC6jEWmnudP6rFTdBHuWMG22ajPl8f2v4Fbv-9Zh6U=.0cb40091-f47b-4bea-8565-42f19304db7b@github.com>
Message-ID: <9Z7D5OqiJILYAXkjvBT3mphDB97T2osJ4Z7TcB9FnTw=.c4f95352-bffd-4f22-8dde-66259e0905e6@github.com>

> When generating `MethodHandle`-based concatenation expressions in `StringConcatFactory` we can reduce the number of classes generated at runtime by creating small batches of prependers and mixers before binding them into the root expression tree. 
> 
> Improvements on one-off tests are modest, while the improvement on bootstrapping stress tests can be substantial ([MixedStringCombinations.java](https://gist.github.com/cl4es/08fb581dece3a73e89bfa52337bc4248)):
> 
> | Build      |    # classes    |   Runtime   |
> | ----------- | ----------------- |  --------------- |
> | Baseline |     31119       |     2.942s     |
> | Patch      |     16208       |     1.958s     |
> 
> An earlier version of this patch saw a regression in the `StringConcatFactoryBootstraps` microbenchmark. After some refactoring along with the optimizations in #8881 and #8923 that is no longer the case, and allocation pressure is down slightly compared to the baseline on such a repeat-the-same-bootstrap stress test:
> 
> Baseline:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2170.039 ?  117.441   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3538.020 ?    4.558    B/op
> 
> This patch:
> 
> Benchmark                                                      Mode  Cnt     Score      Error   Units
> SCFB.makeConcatWithConstants                                   avgt    5  2144.807 ?  162.685   ns/op
> SCFB.makeConcatWithConstants:?gc.alloc.rate.norm               avgt    5  3184.943 ?    4.495    B/op

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Minor stylistic cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8855/files
  - new: https://git.openjdk.java.net/jdk/pull/8855/files/114d3fd8..263db625

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8855&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8855&range=00-01

  Stats: 26 lines in 1 file changed: 6 ins; 10 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8855.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8855/head:pull/8855

PR: https://git.openjdk.java.net/jdk/pull/8855

From jpai at openjdk.java.net  Tue May 31 02:06:37 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 31 May 2022 02:06:37 GMT
Subject: RFR: 8287497: Use String.contains() instead of String.indexOf() in
 java.naming
In-Reply-To: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
References: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
Message-ID: <ytLb0WHDEd-A-7RFVUBbplSYJy2OSZyk95HuxdJmZzg=.48dd0cac-d178-4af7-8fb9-1bcd1f479036@github.com>

On Sun, 29 May 2022 14:00:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `String.contains` was introduced in Java 5.
> Some code in java.naming still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Marked as reviewed by jpai (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8938

From aturbanov at openjdk.java.net  Tue May 31 07:01:40 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 31 May 2022 07:01:40 GMT
Subject: RFR: 8287497: Use String.contains() instead of String.indexOf() in
 java.naming
In-Reply-To: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
References: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
Message-ID: <yUI2qrV2ppZRw_QzWoKrfFNDHzvKX8QqJWsMGLM0P_U=.c070e28e-336d-4a64-aebd-db3f16d912ca@github.com>

On Sun, 29 May 2022 14:00:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `String.contains` was introduced in Java 5.
> Some code in java.naming still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

Thank you for review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8938

From aturbanov at openjdk.java.net  Tue May 31 07:01:41 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 31 May 2022 07:01:41 GMT
Subject: Integrated: 8287497: Use String.contains() instead of String.indexOf()
 in java.naming
In-Reply-To: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
References: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
Message-ID: <GeF3qXRAc1xT1RZlvOXyHx2UADJ8X3AYvi5RgTt10J4=.1d6a5047-53e1-48ac-a8d5-0b597caff90a@github.com>

On Sun, 29 May 2022 14:00:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `String.contains` was introduced in Java 5.
> Some code in java.naming still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

This pull request has now been integrated.

Changeset: 8a9aeff1
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8a9aeff18cd7b26f62934e5892fc87d25f249595
Stats:     13 lines in 4 files changed: 0 ins; 0 del; 13 mod

8287497: Use String.contains() instead of String.indexOf() in java.naming

Reviewed-by: aefimov, rriggs, jpai

-------------

PR: https://git.openjdk.java.net/jdk/pull/8938

From vtewari at openjdk.java.net  Tue May 31 07:17:25 2022
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Tue, 31 May 2022 07:17:25 GMT
Subject: RFR: 8287497: Use String.contains() instead of String.indexOf() in
 java.naming
In-Reply-To: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
References: <dKW0WB3xC74F2pF_YQ6c4_3ru4GFsfPAQ7Q1Uetqui8=.59e7ed1a-74cd-4f69-971e-aee12ff5c0f6@github.com>
Message-ID: <qQ8gJFp4qu66uova_4jT2X3HvXjeJAdoxe0CKQgeZpg=.98b13ae9-125c-4264-b238-488ed3077f19@github.com>

On Sun, 29 May 2022 14:00:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `String.contains` was introduced in Java 5.
> Some code in java.naming still uses old approach with `String.indexOf` to check if String contains specified substring.
> I propose to migrate such usages. Makes code shorter and easier to read.

looks ok to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8938

From aturbanov at openjdk.java.net  Tue May 31 07:18:13 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 31 May 2022 07:18:13 GMT
Subject: RFR: 8287544: Replace uses of StringBuffer with StringBuilder in
 java.naming
Message-ID: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>

StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
There are some code that still uses StringBuffer in java.naming which could be migrated to `StringBuilder`.

-------------

Commit messages:
 - [PATCH] Replace uses of StringBuffer with StringBuilder in java.naming

Changes: https://git.openjdk.java.net/jdk/pull/8942/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8942&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287544
  Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8942.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8942/head:pull/8942

PR: https://git.openjdk.java.net/jdk/pull/8942

From duke at openjdk.java.net  Tue May 31 07:40:56 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 31 May 2022 07:40:56 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v7]
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <veCvzCUCkkwUnk3it7PNliutVgZGQ5osJQE_7lm1kcY=.4384c5bc-cd83-4c25-ac6f-3dcebea5a49c@github.com>

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - 8282662: Revert wrong copyright year change
 - 8282662: Revert ProxyGenerator
 - 8282662: Revert ProxyGenerator
 - 8282662: Revert dubious changes in MethodType
 - 8282662: Revert dubious changes
 - 8282662: Use List/Set.of() factory methods to save memory

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7729/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=06
  Stats: 12 lines in 4 files changed: 1 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7729.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729

PR: https://git.openjdk.java.net/jdk/pull/7729

From duke at openjdk.java.net  Tue May 31 08:14:25 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 31 May 2022 08:14:25 GMT
Subject: RFR: 8287544: Replace uses of StringBuffer with StringBuilder in
 java.naming
In-Reply-To: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
References: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
Message-ID: <hB3v0VVrZ1Pdn9qWDJelgsHn6nUUruqt1z79brZFcBI=.6e076cd7-b37f-4424-8f1f-b0ff67c2ac47@github.com>

On Sun, 29 May 2022 21:57:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
> There are some code that still uses StringBuffer in java.naming which could be migrated to `StringBuilder`.

_not a reviewer_
LGTM

-------------

PR: https://git.openjdk.java.net/jdk/pull/8942

From asotona at openjdk.java.net  Tue May 31 08:40:53 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 31 May 2022 08:40:53 GMT
Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main
 thread on macOS [v6]
In-Reply-To: <ASrwaBWqkJnch7MykKuSxjyhFCAbr32m18Vyt62aMlE=.acf01756-1338-4c00-af9e-2f10037fb3fa@github.com>
References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com>
 <ASrwaBWqkJnch7MykKuSxjyhFCAbr32m18Vyt62aMlE=.acf01756-1338-4c00-af9e-2f10037fb3fa@github.com>
Message-ID: <F0JmqT9NEklOaRal7MIEbXZf55SCrUQBotJZ7jCN3BE=.f021080d-03e6-47a1-8d3c-d5b24911c3d1@github.com>

On Tue, 8 Jun 2021 16:53:38 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> ?d on macOS
>> 
>> This patch simply round up the specified stack size to multiple of the system page size. 
>> 
>> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output.
>> 
>> ```code:java
>> public class StackLeak {
>>     public int depth = 0;
>>     public void stackLeak() {
>>         depth++;
>>         stackLeak();
>>     }
>> 
>>     public static void main(String[] args) {
>>         var test = new StackLeak();
>>         try {
>>             test.stackLeak();
>>         } catch (Throwable e) {
>>             System.out.println(test.depth);
>>         }
>>     }
>> }
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update help text

Continuation in #8953

-------------

PR: https://git.openjdk.java.net/jdk/pull/4256

From asotona at openjdk.java.net  Tue May 31 08:44:49 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 31 May 2022 08:44:49 GMT
Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main
 thread on macOS
Message-ID: <sQQNTUkoRVDb14y4H_NSxubNI-4IFg_F-VE9-z_D6WY=.a6bdb960-04e7-483e-9193-3c0fab74e175@github.com>

This is continuation of PR #4256 

The patch simply rounds up the specified stack size to multiple of the system page size, on systems where necessary.
The patch is based on the original PR/branch, with reflected remaining recommendations.

Please review.

Thank you,
Adam

-------------

Commit messages:
 - puting EINVAL on the RHS of the == as recommended
 - Update help text
 - Cast type
 - Change java -X output for -Xss
 - Only try to round-up when current value failed
 - Avoid overflow on page size
 - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS

Changes: https://git.openjdk.java.net/jdk/pull/8953/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8953&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236569
  Stats: 41 lines in 3 files changed: 39 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8953.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8953/head:pull/8953

PR: https://git.openjdk.java.net/jdk/pull/8953

From asotona at openjdk.java.net  Tue May 31 09:39:27 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 31 May 2022 09:39:27 GMT
Subject: RFR: 8286571: java source launcher from a minimal jdk image
 containing jdk.compiler fails with --enable-preview option [v3]
In-Reply-To: <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
References: <I2TA2UYFHxaFfb_5q_mdyc9sH73FV7MduAyDQ63w280=.37ba7d2f-49d6-4da3-8e5d-38a218bcc835@github.com>
 <AvQ1uVPqW_gOqFaNpoFbTCnziTz3oTPXQAWwvJbGpMw=.c8c13b7b-8bbc-451b-b460-6dc6a75b3787@github.com>
Message-ID: <9FbplkFd9TjZnpIm_xNikh3Q80b5h0ELoLL5RADbyXw=.d83fdcc0-2ab0-4a8a-a45e-dda9af644cd1@github.com>

On Wed, 18 May 2022 06:30:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> ### Problem description
>> Minimal jdk image created by jlink with the only jdk.compiler module and its dependencies
>> fails to run java source launcher correctly (for example when --source N is specified).
>> Failing source launcher is only one the expressions of internal jdk.compiler malfunction, another example is failure to run javac with --release option.
>> 
>> ### Root cause
>> Module jdk.compiler requires zip filesystem (jdk.zipfs module) to parse ct.sym file and so to provide full functionality.
>> Module jdk.zipfs is not included in the minimal JDK image, because module jdk.compiler does not declare it as "requires" in its module info.
>> 
>> ### Alternative patch
>> The problem can be alternatively resolved by complex code checks in jdk.compiler to provide user with valid error message, however that solution would be just a workaround for jdk.compiler dual functionality (with or without presence of jdk.zipfs module). Compiler functionality without access to ct.sym through jdk.zipfs is very limited. 
>> 
>> ### Proposed fix
>> This patch fixes the problem by explicit declaration of jdk.compiler dependency on jdk.zipfs.
>> Plus added specific test case.
>> 
>> Please review the patch or raise objections against declaration of jdk.compiler dependent on jdk.zipfs.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   corrected LimitedImage test description

Followup issues to narrow the situation with optional module dependencies have been filled:
- [8287559: Jlink should warn user about unsatisfied optional modules dependencies](https://bugs.openjdk.java.net/browse/JDK-8287559)
- [8287560: jdk.compiler dependency on jdk.zipfs should be declared as optional](https://bugs.openjdk.java.net/browse/JDK-8287560)

Please review if you agree with actual patch adding jdk.compiler dependency on jdk.zips.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8747

From redestad at openjdk.java.net  Tue May 31 09:40:27 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 31 May 2022 09:40:27 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v7]
In-Reply-To: <veCvzCUCkkwUnk3it7PNliutVgZGQ5osJQE_7lm1kcY=.4384c5bc-cd83-4c25-ac6f-3dcebea5a49c@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <veCvzCUCkkwUnk3it7PNliutVgZGQ5osJQE_7lm1kcY=.4384c5bc-cd83-4c25-ac6f-3dcebea5a49c@github.com>
Message-ID: <sMixpPWc6Vp1xvfgBydB3OsQghldhaTpkZ5_PV_r7l0=.6a84202e-8d5a-4623-91b4-3914f5ffc3a2@github.com>

On Tue, 31 May 2022 07:40:56 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - 8282662: Revert wrong copyright year change
>  - 8282662: Revert ProxyGenerator
>  - 8282662: Revert ProxyGenerator
>  - 8282662: Revert dubious changes in MethodType
>  - 8282662: Revert dubious changes
>  - 8282662: Use List/Set.of() factory methods to save memory

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From shade at openjdk.java.net  Tue May 31 10:34:29 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 May 2022 10:34:29 GMT
Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437
In-Reply-To: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
Message-ID: <ws3KBGCtl3vrtNgpNUuoUuiTlkSR1HGPfqsFJ9VoImg=.e4a15d5c-be84-46b1-bf63-771972c57bad@github.com>

On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
> 
> Additional testing:
>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>  - [x] Linux x86_32 fastdebug `tier1`
>  - [ ] GHA run

Open for reviews. The test failures on Windows x64 are known and are solved separately.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8946

From alanb at openjdk.java.net  Tue May 31 11:43:14 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 31 May 2022 11:43:14 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps to
 OS thread
Message-ID: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>

This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:

1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)

The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

-------------

Commit messages:
 - Continuation clinit should fail if no continuations support
 - Fix merge issue with test
 - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION
 - Update
 - Expend test coverage
 - Merge
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/8939/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287496
  Stats: 742 lines in 71 files changed: 570 ins; 53 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8939.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8939/head:pull/8939

PR: https://git.openjdk.java.net/jdk/pull/8939

From duke at openjdk.java.net  Tue May 31 11:43:15 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Tue, 31 May 2022 11:43:15 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread
In-Reply-To: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
Message-ID: <7FdpvW58T55cnXD59rW5-71p7ENg2Q7BNfW5djYTGuU=.0fda930a-6b25-4be3-b329-945b9734d6d7@github.com>

On Sun, 29 May 2022 14:46:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
> 
> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
> 
> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

Since?the?package `jdk.internal.access` is?exported[^1] to?the?`java.management`?module, this?can?use `MethodHandle`s obtained?using the?trusted?lookup.

[^1]: https://github.com/openjdk/jdk/blob/73ba7fdce838ba8a2c227a972c176311e6cc0b41/src/java.base/share/classes/module-info.java#L151-L154

src/java.management/share/classes/java/lang/management/ThreadInfo.java line 971:

> 969:             throw new InternalError(e);
> 970:         }
> 971:     }

Suggestion:

    private static boolean isVirtual(Thread thread) {
        try {
            return (boolean) IS_VIRTUAL.invokeExact(thread);
        } catch (Error | RuntimeException e) {
            throw e;
        } catch (Throwable t) {
            throw new InternalError(t);
        }
    }

    private static final MethodHandle IS_VIRTUAL;
    static {
        final JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess();
        try {
            MethodHandle m = JLIA.findVirtual(Thread.class, "isVirtual", MethodType.methodType(boolean.class));
            assert m != null;
            IS_VIRTUAL = m;
        } catch (Exception e) {
            throw new InternalError(e);
        }
    }

src/java.management/share/classes/sun/management/ThreadImpl.java line 661:

> 659: 
> 660:     private static final Method THREAD_IS_VIRTUAL = threadIsVirtual();
> 661:     private static final Field THREADINFO_VIRTUAL = threadInfoVirtual();

Suggestion:

    private static boolean isVirtual(Thread thread) {
        try {
            return (boolean) THREAD_IS_VIRTUAL.invokeExact(thread);
        } catch (Error | RuntimeException e) {
            throw e;
        } catch (Throwable t) {
            throw new InternalError(t);
        }
    }

    /**
     * Returns true if the given ThreadInfo is for a virutal thread.
     */
    private static boolean isVirtual(ThreadInfo threadInfo) {
        try {
            return (boolean) THREADINFO_VIRTUAL.invokeExact(threadInfo);
        } catch (Error | RuntimeException e) {
            throw e;
        } catch (Throwable t) {
            throw new InternalError(t);
        }
    }

    private static final JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess();

    private static MethodHandle threadIsVirtual() {
        try {
            MethodHandle m = JLIA.findVirtual(Thread.class, "isVirtual", MethodType.methodType(boolean.class));
            assert m != null;
            return m;
        } catch (Exception e) {
            throw new InternalError(e);
        }
    }

    @SuppressWarnings("removal")
    private static MethodHandle threadInfoVirtual() {
        PrivilegedExceptionAction<Field> pa = () -> ThreadInfo.class.getDeclaredField("virtual");
        try {
            return JLIA.unreflectField(AccessController.doPrivileged(pa), false);
        } catch (Exception e) {
            throw new InternalError(e);
        }
    }

    private static final MethodHandle THREAD_IS_VIRTUAL = threadIsVirtual();
    private static final MethodHandle THREADINFO_VIRTUAL = threadInfoVirtual();

-------------

PR: https://git.openjdk.java.net/jdk/pull/8939

From alanb at openjdk.java.net  Tue May 31 11:43:15 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 31 May 2022 11:43:15 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread
In-Reply-To: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
Message-ID: <wMOLbw8a7kxhxaTQUFTL5d5-XL5MBqDHiD1Dqm3i5sM=.a6714b0a-c1cf-4cf0-a0bf-30e3723248ac@github.com>

On Sun, 29 May 2022 14:46:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
> 
> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
> 
> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

> Since?the?package `jdk.internal.access` is?exported[1](#user-content-fn-1-97aea7d7960164849e591e42b91fb5c4) to?the?`java.management`?module, this?can?use `MethodHandle`s obtained?using the?trusted?lookup.

That export is for another reason, and probably should be re-examined so that java.base doesn't need to export this package to java.management. In any case, we expect there will be compiler support soon to allow java.management be compiled with code that makes use of preview APIs in java.base. That will at least us reference Thread::isVirtual from code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8939

From alanb at openjdk.java.net  Tue May 31 11:47:48 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 31 May 2022 11:47:48 GMT
Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437
In-Reply-To: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
Message-ID: <ghz7LkXixuRxYvAy3J1wrJi_UysWA7sgo4FsKTelqu4=.2f310a57-6e5e-4464-8198-22175d868643@github.com>

On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
> 
> Additional testing:
>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>  - [x] Linux x86_32 fastdebug `tier1`
>  - [ ] GHA run

This looks okay.  If we get PR8939 in then it should be possible to do more clear out of the exclude lists.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8946

From rriggs at openjdk.java.net  Tue May 31 13:13:47 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 31 May 2022 13:13:47 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v7]
In-Reply-To: <veCvzCUCkkwUnk3it7PNliutVgZGQ5osJQE_7lm1kcY=.4384c5bc-cd83-4c25-ac6f-3dcebea5a49c@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <veCvzCUCkkwUnk3it7PNliutVgZGQ5osJQE_7lm1kcY=.4384c5bc-cd83-4c25-ac6f-3dcebea5a49c@github.com>
Message-ID: <fNyCeRSyuJFe1gJvKHdDjqJlNMtLheJc1yw7pg-w9Wc=.5f4727b7-1c6d-426a-9c7c-547b0a07730b@github.com>

On Tue, 31 May 2022 07:40:56 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? 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 six additional commits since the last revision:
> 
>  - 8282662: Revert wrong copyright year change
>  - 8282662: Revert ProxyGenerator
>  - 8282662: Revert ProxyGenerator
>  - 8282662: Revert dubious changes in MethodType
>  - 8282662: Revert dubious changes
>  - 8282662: Use List/Set.of() factory methods to save memory

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From rriggs at openjdk.java.net  Tue May 31 13:30:48 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 31 May 2022 13:30:48 GMT
Subject: RFR: 8287544: Replace uses of StringBuffer with StringBuilder in
 java.naming
In-Reply-To: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
References: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
Message-ID: <InX3hThfDElL2inyQz-OSkMyKLX1igJf_fqf2RYTnUQ=.cc782868-e80a-4505-80ad-ec19801ab876@github.com>

On Sun, 29 May 2022 21:57:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
> There are some code that still uses StringBuffer in java.naming which could be migrated to `StringBuilder`.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8942

From aefimov at openjdk.java.net  Tue May 31 13:35:40 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 31 May 2022 13:35:40 GMT
Subject: RFR: 8287544: Replace uses of StringBuffer with StringBuilder in
 java.naming
In-Reply-To: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
References: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
Message-ID: <a9RRUNf8AdIpERURHLCgP9rwuS436iiWl7oQskZMnDQ=.2ad2e2f5-6d7f-400c-be84-0df62a6fccbf@github.com>

On Sun, 29 May 2022 21:57:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
> There are some code that still uses StringBuffer in java.naming which could be migrated to `StringBuilder`.

Looks good to me ??

-------------

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8942

From dholmes at openjdk.java.net  Tue May 31 13:36:48 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 31 May 2022 13:36:48 GMT
Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main
 thread on macOS
In-Reply-To: <sQQNTUkoRVDb14y4H_NSxubNI-4IFg_F-VE9-z_D6WY=.a6bdb960-04e7-483e-9193-3c0fab74e175@github.com>
References: <sQQNTUkoRVDb14y4H_NSxubNI-4IFg_F-VE9-z_D6WY=.a6bdb960-04e7-483e-9193-3c0fab74e175@github.com>
Message-ID: <IH8cx5sDGHWbZ7-ufLfml5FwcY8IOibnoA1AdZDtFvQ=.f47aa20e-f902-4f72-9a2d-9cc26b77ca9e@github.com>

On Tue, 31 May 2022 08:37:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This is continuation of PR #4256 
> 
> The patch simply rounds up the specified stack size to multiple of the system page size, on systems where necessary.
> The patch is based on the original PR/branch, with reflected remaining recommendations.
> 
> Please review.
> 
> Thank you,
> Adam

Changes looks good. But the java manpage needs an update too.

Thanks,
David

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 176:

> 174: \    -Xss<size>        set java thread stack size\n\
> 175: \                      The actual size may be rounded up to a multiple of the\n\
> 176: \                      system page size as required by the operating system.\n\

The Java manpage will also need this update.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8953

From dfuchs at openjdk.java.net  Tue May 31 13:36:55 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 31 May 2022 13:36:55 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
Message-ID: <I6NZh4eZvMP3l1P-7RGh21Et0CcGwrBCc3co0rQRnRs=.dd4df743-4b15-4c7c-aaea-3c40481a31e4@github.com>

On Thu, 26 May 2022 18:50:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this test update reviewed?
> 
> The ForceGC could be enhanced by using smaller wait/sleep time, and shared cleaner.
> 
> Thanks,
> Xuelei

LGTM - but it may be good to have an other reviewer (@mlchung ?)

test/lib/jdk/test/lib/util/ForceGC.java line 50:

> 48:             for (int i = 0; i < 100; i++) {
> 49:                 System.gc();
> 50:                 System.out.println("doIt() iter: " + iter + ", gc " + i);

Maybe the trace should be printed only if `(i % 10 == 0) && (iter % 100 == 0)` to avoid having too many traces in the log?

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8907

From rriggs at openjdk.java.net  Tue May 31 13:55:32 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 31 May 2022 13:55:32 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <apPTENS4Q7-tQYOz53z0pHg-uApVCpkJT2h39SyY9k4=.e6e51e4a-5504-42ce-8bba-e9e8b7169b09@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
 <apPTENS4Q7-tQYOz53z0pHg-uApVCpkJT2h39SyY9k4=.e6e51e4a-5504-42ce-8bba-e9e8b7169b09@github.com>
Message-ID: <S0yoqyj69x_ljV33s_NzIa8E-6y36g3dtoB6mHadLp8=.0206550a-1745-4c84-a988-7a9ff932a7f0@github.com>

On Fri, 27 May 2022 20:21:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> With the `AccessFlag` API, what is the role of the `Modifier` API going forward? [Value Objects JEP](https://openjdk.java.net/jeps/8277163) defines the new `identity` and `value` modifiers. [PR #698](https://github.com/openjdk/valhalla/pull/698) proposes to add `Modifier.IDENTITY` and `Modifier.VALUE` constants as the `identity` and `value` modifiers are encoded in a class file using the `ACC_IDENTITY` and `ACC_VALUE` flags. However, with the new improved `AccessFlag` API, the new flags will be defined in the `AccessFlag` API. I think we should avoid adding the new flags in `Modifier` and leave it for the existing usage. Use `AccessFlag` for new features.

Looking over the existing uses of Modifier, as relates to Class.getModifiers(), there are simple uses testing for an individual access flag and others that expect a full set of modifier bits that apply to the class. There are a few places that need all the bits to compose a new set of modifier bits and a few others that test for combinations of bits.
`Class.getModifiers()` is intrinsified, testing against various bit patterns using the static methods of `Modifier` is very performant.

The `Modifer.toString()` method cannot distinguish the flags overloaded by the Class vs Member cases.
Modifier.toString() is used by both Class and Member `toString` methods.
Methods to convert a Set<AccessFlag> to a mask and to produce the 'toString' of the set would be useful.

To replace all uses of Modifier the existing use cases will need some attention.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From shade at openjdk.java.net  Tue May 31 14:03:42 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 May 2022 14:03:42 GMT
Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437
In-Reply-To: <ghz7LkXixuRxYvAy3J1wrJi_UysWA7sgo4FsKTelqu4=.2f310a57-6e5e-4464-8198-22175d868643@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
 <ghz7LkXixuRxYvAy3J1wrJi_UysWA7sgo4FsKTelqu4=.2f310a57-6e5e-4464-8198-22175d868643@github.com>
Message-ID: <J5IU0BsxDE88Le03wdc3WaGL7uRrDqRyWUEC_X67UZw=.93efc962-fee2-4e81-8e9b-fe14911d7040@github.com>

On Tue, 31 May 2022 11:44:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
>> 
>> Additional testing:
>>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>>  - [x] Linux x86_32 fastdebug `tier1`
>>  - [x] GHA run
>
> This looks okay.  If we get PR8939 in then it should be possible to do more clear out of the exclude lists.

Thank you, @AlanBateman. Any other comments? I plan to integrate it soon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8946

From asotona at openjdk.java.net  Tue May 31 15:10:38 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 31 May 2022 15:10:38 GMT
Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main
 thread on macOS [v2]
In-Reply-To: <sQQNTUkoRVDb14y4H_NSxubNI-4IFg_F-VE9-z_D6WY=.a6bdb960-04e7-483e-9193-3c0fab74e175@github.com>
References: <sQQNTUkoRVDb14y4H_NSxubNI-4IFg_F-VE9-z_D6WY=.a6bdb960-04e7-483e-9193-3c0fab74e175@github.com>
Message-ID: <1PZgAXmfp27EHTdkT27VbWMHJQn-4BsbytSZBUgqhS0=.5ca7cb41-529e-4869-9a67-314e3e07ee22@github.com>

> This is continuation of PR #4256 
> 
> The patch simply rounds up the specified stack size to multiple of the system page size, on systems where necessary.
> The patch is based on the original PR/branch, with reflected remaining recommendations.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Updated Java mannpage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8953/files
  - new: https://git.openjdk.java.net/jdk/pull/8953/files/d082aed0..7712f700

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8953&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8953&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8953.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8953/head:pull/8953

PR: https://git.openjdk.java.net/jdk/pull/8953

From asotona at openjdk.java.net  Tue May 31 15:10:41 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Tue, 31 May 2022 15:10:41 GMT
Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main
 thread on macOS [v2]
In-Reply-To: <IH8cx5sDGHWbZ7-ufLfml5FwcY8IOibnoA1AdZDtFvQ=.f47aa20e-f902-4f72-9a2d-9cc26b77ca9e@github.com>
References: <sQQNTUkoRVDb14y4H_NSxubNI-4IFg_F-VE9-z_D6WY=.a6bdb960-04e7-483e-9193-3c0fab74e175@github.com>
 <IH8cx5sDGHWbZ7-ufLfml5FwcY8IOibnoA1AdZDtFvQ=.f47aa20e-f902-4f72-9a2d-9cc26b77ca9e@github.com>
Message-ID: <pe1VEXOMnw1kK6FKd2X8NFncd8nuS5JdvUpoazUzfgQ=.132cd71b-4895-47e0-b7cf-f628b5441941@github.com>

On Tue, 31 May 2022 13:28:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated Java mannpage
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 176:
> 
>> 174: \    -Xss<size>        set java thread stack size\n\
>> 175: \                      The actual size may be rounded up to a multiple of the\n\
>> 176: \                      system page size as required by the operating system.\n\
> 
> The Java manpage will also need this update.

Thanks for reminder, I've update Java manpage at both locations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8953

From alanb at openjdk.java.net  Tue May 31 15:39:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 31 May 2022 15:39:39 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
Message-ID: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>

> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
> 
> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
> 
> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Allowing linking without intrinsic stub, contributed-by: rehn

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8939/files
  - new: https://git.openjdk.java.net/jdk/pull/8939/files/7989708b..126e38b6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=00-01

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8939.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8939/head:pull/8939

PR: https://git.openjdk.java.net/jdk/pull/8939

From jbhateja at openjdk.java.net  Tue May 31 16:04:55 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 31 May 2022 16:04:55 GMT
Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator) [v10]
In-Reply-To: <VHAcCWLYeUyK0upiw42TqjQ_FvoSrzj2bLEFbvkZCF8=.165b6038-072b-4d77-a070-461604c782c7@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
 <VHAcCWLYeUyK0upiw42TqjQ_FvoSrzj2bLEFbvkZCF8=.165b6038-072b-4d77-a070-461604c782c7@github.com>
Message-ID: <IQ-i8qIElCfMNMbyI030A5FKCf5Bw4v2i98Rk0r_jR8=.185b97d3-a380-4fe3-b9e4-5afe1b326966@github.com>

On Wed, 25 May 2022 06:29:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
>> 
>> Following is the brief summary of changes:-
>> 
>> 1)  Extends the scope of existing lanewise API for following new vector operations.
>>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>>    - VectorOperations.REVERSE: reversing the order of bits
>>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
>> 
>> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>>    - Vector.compress
>>    - Vector.expand 
>>    - VectorMask.compress
>> 
>> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>>   - Vector.fromMemorySegment
>>   - Vector.intoMemorySegment
>> 
>> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
>> 
>> 
>>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
>> 
>>  Kindly review and share your feedback.
>> 
>>  Best Regards,
>>  Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - 8284960: Post merge cleanups.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Review comments resolved.
>  - 8284960: Integrating incremental patches.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms.
>  - 8284960: Adding --enable-preview in vectorAPI benchmarks.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - 8284960: Review comments resolution.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/742644e2...0f6e1584

Thanks reviewers for your comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From jbhateja at openjdk.java.net  Tue May 31 16:04:58 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 31 May 2022 16:04:58 GMT
Subject: Integrated: 8284960: Integration of JEP 426: Vector API (Fourth
 Incubator)
In-Reply-To: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
References: <iltelIfsjSD8MdYmZVzzTh7G8J0_lKmjvipy-N4LXsQ=.a54f4129-916f-4244-90ec-f23f3306fb79@github.com>
Message-ID: <yW8sQA3Haq8xpzcTiUbKOnoMSmiK95eKoUjlnBTqMhw=.970b804c-6ed3-40b0-bc65-456ead9d89d2@github.com>

On Wed, 27 Apr 2022 11:03:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173)
> 
> Following is the brief summary of changes:-
> 
> 1)  Extends the scope of existing lanewise API for following new vector operations.
>    -  VectorOperations.BIT_COUNT: counts the number of one-bits
>    - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits
>    - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits
>    - VectorOperations.REVERSE: reversing the order of bits
>    - VectorOperations.REVERSE_BYTES: reversing the order of bytes
>    - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract.
> 
> 2)  Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask.
>    - Vector.compress
>    - Vector.expand 
>    - VectorMask.compress
> 
> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. 
>   - Vector.fromMemorySegment
>   - Vector.intoMemorySegment
> 
> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation.
> 
> 
>  Patch has been regressed over AARCH64 and X86 targets different AVX levels. 
> 
>  Kindly review and share your feedback.
> 
>  Best Regards,
>  Jatin

This pull request has now been integrated.

Changeset: 6f6486e9
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6f6486e97743eadfb20b4175e1b4b2b05b59a17a
Stats:     38021 lines in 228 files changed: 16652 ins; 16924 del; 4445 mod

8284960: Integration of JEP 426: Vector API (Fourth Incubator)

Co-authored-by: Jatin Bhateja <jbhateja at openjdk.org>
Co-authored-by: Paul Sandoz <psandoz at openjdk.org>
Co-authored-by: Sandhya Viswanathan <sviswanathan at openjdk.org>
Co-authored-by: Smita Kamath <svkamath at openjdk.org>
Co-authored-by: Joshua Zhu <jzhu at openjdk.org>
Co-authored-by: Xiaohong Gong <xgong at openjdk.org>
Co-authored-by: John R Rose <jrose at openjdk.org>
Co-authored-by: Eric Liu <eliu at openjdk.org>
Co-authored-by: Ningsheng Jian <njian at openjdk.org>
Reviewed-by: ngasson, vlivanov, mcimadamore, jlahoda, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/8425

From vtewari at openjdk.java.net  Tue May 31 16:12:41 2022
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Tue, 31 May 2022 16:12:41 GMT
Subject: RFR: 8287544: Replace uses of StringBuffer with StringBuilder in
 java.naming
In-Reply-To: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
References: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
Message-ID: <_gr6T4NlkiI2Tu473_oSKdEaqdGtwLHUgQeZgwXbCRQ=.64e59901-7e4f-416e-b516-f6215c166c15@github.com>

On Sun, 29 May 2022 21:57:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
> There are some code that still uses StringBuffer in java.naming which could be migrated to `StringBuilder`.

Looks ok.

-------------

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8942

From aefimov at openjdk.java.net  Tue May 31 16:28:41 2022
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 31 May 2022 16:28:41 GMT
Subject: RFR: 8287544: Replace uses of StringBuffer with StringBuilder in
 java.naming
In-Reply-To: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
References: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
Message-ID: <g4l0yLuTioWyZt3ta4LtaTzU9FSW-3SGoRCjneWh7k4=.f5e0d480-a464-4a9b-b3bc-e073f9deae09@github.com>

On Sun, 29 May 2022 21:57:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
> There are some code that still uses StringBuffer in java.naming which could be migrated to `StringBuilder`.

> Looks good to me +1

`java.naming` regression tests also happy with the change - no new failures

-------------

PR: https://git.openjdk.java.net/jdk/pull/8942

From psandoz at openjdk.java.net  Tue May 31 16:51:47 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 31 May 2022 16:51:47 GMT
Subject: RFR: 8286279: [vectorapi] Only check index of masked lanes if
 offset is out of array boundary for masked store [v2]
In-Reply-To: <uJLpkCZdNUpfugjsnuUpiXQp29CS64WvqX98HsMMW-M=.9994429f-9e95-4cd9-b20f-7501cb647af1@github.com>
References: <nFnUG6NkfXVV8oleVQiqKJgs1IWpl_5aFkml41Zo35A=.7de50f84-6860-4b28-83ad-e7afc8c2c062@github.com>
 <Xc3eRxaJ7ISiF8r7QgLgc-V-PkxpWdgiGFe6kwhr3-E=.d5275628-cd3f-497b-89e7-57f14debb5bc@github.com>
 <uJLpkCZdNUpfugjsnuUpiXQp29CS64WvqX98HsMMW-M=.9994429f-9e95-4cd9-b20f-7501cb647af1@github.com>
Message-ID: <1MDYeqST0lYsav_o10jKIr3Fgoqo1Fn9aKYP9kMpN0M=.0bc88db0-84b6-48d5-a021-2ba302a46d92@github.com>

On Mon, 30 May 2022 01:17:00 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrap the offset check into a static method
>
> @PaulSandoz, could you please help to check whether the current version is ok for you? Thanks so much!

@XiaohongGong looks good, now the Vector API JEP has been integrated you will get a merge conflict, but it should be easier to resolve.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8620

From bulasevich at openjdk.java.net  Tue May 31 16:58:42 2022
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Tue, 31 May 2022 16:58:42 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
Message-ID: <t3_rXPchNY-df1u0SOxZUX1eqXSA6Ca4_8kz4sVumCg=.ce68380d-a517-41bc-bf02-3e4035bd668e@github.com>

On Tue, 31 May 2022 15:39:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
>> 
>> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
>> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
>> 
>> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allowing linking without intrinsic stub, contributed-by: rehn

I expected this change to fix the broken ARM32 port, but it doesn't work.

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (templateInterpreterGenerator_arm.cpp:732), pid=27345, tid=27346
#  Error: Unimplemented()
#
# JRE version:  (19.0) (build )
# Java VM: OpenJDK Server VM (19-commit6f6486e9-adhoc.re.jdk, mixed mode, g1 gc, linux-arm)
# Problematic frame:
# V  [libjvm.so+0xa14fe0]  TemplateInterpreterGenerator::generate_Continuation_doYield_entry()+0x2c

-------------

PR: https://git.openjdk.java.net/jdk/pull/8939

From duke at openjdk.java.net  Tue May 31 17:07:06 2022
From: duke at openjdk.java.net (Raffaello Giulietti)
Date: Tue, 31 May 2022 17:07:06 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
Message-ID: <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>

> Hello,
> 
> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
> 
> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
> 
> 
> Greetings
> Raffaello

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  4511638: Double.toString(double) sometimes produces incorrect results

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3402/files
  - new: https://git.openjdk.java.net/jdk/pull/3402/files/31ca4e10..ad146ec4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3402&range=12-13

  Stats: 19594 lines in 1 file changed: 0 ins; 19594 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402

PR: https://git.openjdk.java.net/jdk/pull/3402

From shade at openjdk.java.net  Tue May 31 17:07:43 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 May 2022 17:07:43 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <t3_rXPchNY-df1u0SOxZUX1eqXSA6Ca4_8kz4sVumCg=.ce68380d-a517-41bc-bf02-3e4035bd668e@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
 <t3_rXPchNY-df1u0SOxZUX1eqXSA6Ca4_8kz4sVumCg=.ce68380d-a517-41bc-bf02-3e4035bd668e@github.com>
Message-ID: <jojfLI3jGW_hWmqexEbMsfzaby1mpk__Dftyx6QGulQ=.2a82ccd0-a9dd-4b1a-a28d-aed331490dec@github.com>

On Tue, 31 May 2022 16:54:41 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> I expected this change to fix the broken ARM32 port, but it doesn't work.

It would not fix ARM32, because the interpreter stubs need to be predicated on `Continuations::enabled()`. Also, as my ARM32 experiments show (https://github.com/openjdk/jdk/pull/8634/files#diff-027490ce3f4a92be9b489d9d2e54c7baaea87b7489399b198543c79f1ce1e2e3R4208-R4216) -- there is a breakage somewhere in C2 as well, which this patch would not seem to resolve as well. So, this is a stepping stone for *some* support, but it does not resolve porting situation fully.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8939

From shade at openjdk.java.net  Tue May 31 17:10:33 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 May 2022 17:10:33 GMT
Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437 [v2]
In-Reply-To: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
References: <A4HerqbjGt4ZTqEDhH9p2jqQpW9vJmfN9JtkqfjG-u8=.5ae759fb-8cfc-492f-9f44-5d95e42148f2@github.com>
Message-ID: <VyKpscMr_TrwvuceTHSCJP39sq5pzFiUuj3vsXyg1iE=.3c5506a8-c2b8-4ff0-8559-baa7b94dcab3@github.com>

> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now.
> 
> Additional testing:
>  - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures
>  - [x] Linux x86_32 fastdebug `tier1`
>  - [x] GHA run

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8287520-loom-x86-32-shrink
 - Keep GetEventWriter on problemlist
 - Fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8946/files
  - new: https://git.openjdk.java.net/jdk/pull/8946/files/7c90ead6..a3c3db2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8946&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8946&range=00-01

  Stats: 38619 lines in 252 files changed: 17091 ins; 16971 del; 4557 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8946.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8946/head:pull/8946

PR: https://git.openjdk.java.net/jdk/pull/8946

From alanb at openjdk.java.net  Tue May 31 17:10:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 31 May 2022 17:10:45 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <jojfLI3jGW_hWmqexEbMsfzaby1mpk__Dftyx6QGulQ=.2a82ccd0-a9dd-4b1a-a28d-aed331490dec@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
 <t3_rXPchNY-df1u0SOxZUX1eqXSA6Ca4_8kz4sVumCg=.ce68380d-a517-41bc-bf02-3e4035bd668e@github.com>
 <jojfLI3jGW_hWmqexEbMsfzaby1mpk__Dftyx6QGulQ=.2a82ccd0-a9dd-4b1a-a28d-aed331490dec@github.com>
Message-ID: <CiOq7WhBN19qrIhclF6xWxS7ii8QXKaxRul0MQ-mYGg=.7e325d78-b6c1-4a12-91e6-fb971ce2c5fa@github.com>

On Tue, 31 May 2022 17:03:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I expected this change to fix the broken ARM32 port, but it doesn't work.

There is work required to get the arm32 port working again, currently tracked as JDK-828636 but there may be further issues beyond that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8939

From mchung at openjdk.java.net  Tue May 31 17:15:09 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 31 May 2022 17:15:09 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <vRrPgvtEEe9e0CEbMCuT61afcTqMxCpZ5pcCG2nHLGY=.2af00dbc-fdae-490a-a874-8bd326f4278c@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/3d558a34...05cf2d8b

I think `Modifier` API is as good as it is right now.   The question is whether we keep `Modifier` API as is for the existing usage or enhancing it for the new modifiers such as `value` and `primitive`.     No benefit of replacing existing uses of `Modifier` to the new `AccessFlag` API as most existing use are simple tests to determine if it's public, static, final, non-public etc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From naoto at openjdk.java.net  Tue May 31 17:25:42 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 31 May 2022 17:25:42 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v4]
In-Reply-To: <UCmcIC38gTHOC4h24nU36xV973FAPzOYVeN5UEKGt7E=.80b8b023-b3cd-4fa6-8833-5c12b59e45d9@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <UCmcIC38gTHOC4h24nU36xV973FAPzOYVeN5UEKGt7E=.80b8b023-b3cd-4fa6-8833-5c12b59e45d9@github.com>
Message-ID: <Pc26qPovgWchtLlJWnCCx7tv1i0uhgQYmNji-aJylEA=.6dd31410-f275-479d-8073-8f333d8a5035@github.com>

On Mon, 30 May 2022 15:40:37 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
>  - Merge branch '8285838' of github.com:Deigue/jdk into 8285838

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 67:

> 65:         if ((month > Month.MARCH.getValue() && month < Month.OCTOBER.getValue()) ||
> 66:                 (month == Month.MARCH.getValue() && date.isAfter(getLastSundayOfMonth(date))) ||
> 67:                 (month == Month.OCTOBER.getValue() && date.isBefore(getLastSundayOfMonth(date)))) {

I don't think these conditions are correct, as `month` is zero-based, and comparing it with `Month.MARCH` will be incorrect. The same holds for October.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From forax at openjdk.java.net  Tue May 31 17:26:20 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 31 May 2022 17:26:20 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <1CcWL2DOXfuqRNL1vX2E7PH99YUCE3oxBV-S7hCCYao=.ff847c06-17aa-4930-a90b-dac086f25991@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/1545e825...05cf2d8b

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 130:

> 128:         MANDATED(AccessFlag.MANDATED.mask());
> 129: 
> 130:         private int mask;

it should be declared final ?

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 134:

> 132:             this.mask = mask;
> 133:         }
> 134:         private int mask() {return mask;}

seem useless, `mask` can be accessed directly

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From forax at openjdk.java.net  Tue May 31 17:26:21 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 31 May 2022 17:26:21 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v4]
In-Reply-To: <MEtN7J3iCVfGc0r4wROtdjMCGwUl1ujS6kj73VnGZYI=.e2a38f27-f7e0-41b3-9ee3-5f716087f167@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1aXf7Ta_8stk6lanmV7TSsEgshx7GP-Vkhrur89uGtg=.60cf86be-7523-49fb-8ee1-42cf83cfd153@github.com>
 <kLt6tmrBcXJuCkEyc8MJqpCAFIHlwlXqCWesifJujd0=.3ba9ae2f-db6a-498c-9b3d-9502941a7786@github.com>
 <deXxKDbG8iZ116d8G2o7g_XCxkIOGsk6UB1l9Im5Be8=.95e8c3f2-7f53-4d09-8616-a5c9c0172b12@github.com>
 <MEtN7J3iCVfGc0r4wROtdjMCGwUl1ujS6kj73VnGZYI=.e2a38f27-f7e0-41b3-9ee3-5f716087f167@github.com>
Message-ID: <9zRdxb7kB5HwcMkN11Zw6RiSG5KgtxYe-UCUonFyQ34=.b1e6abf7-2c8e-4311-bcb2-6d1fb87f7cac@github.com>

On Tue, 15 Feb 2022 21:05:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Note?that the?presence or?absence of?`ACC_SUPER` has?no?effect since?**Java?8**, which?always treats?it as?set regardless?of the?actual?contents of?the?binary class?file.
>
> For completeness, I think including SUPER is reasonable, even though has been a no-op for some time. (Some time in the future, there could be a class file version aware additions to this enum class.) Well spotted omission.

`ACC_SUPER`may be reconed as `ACC_IDENTITY`by Valhalla, so i'm not sure it's a good idea to add ACC_SUPER.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From forax at openjdk.java.net  Tue May 31 17:29:02 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 31 May 2022 17:29:02 GMT
Subject: RFR: JDK-8266670: Better modeling of access flags in core
 reflection [v20]
In-Reply-To: <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
References: <V_Pzmnjdocn8XV2eaIf1REStWAScalvqMXlfRL6e82w=.437550ff-65ca-4c52-816a-c2be0fb2d279@github.com>
 <1oIXvLwJ8nQsS2PFR_sEiLrCj8cNWuRH8YW3RXWWzBk=.0b2f699d-eb05-4c15-938b-1747f941a0a7@github.com>
Message-ID: <H4nZJ6RTEc3DpQkv4QhvcJUUPU3jGbwhxHoW_vDYSxs=.c0843e5c-8080-4b31-985a-35ed172cd587@github.com>

On Wed, 25 May 2022 00:35:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Target JDK 20 rather than 19.
>  - Merge branch 'master' into JDK-8266670
>  - Add mask values to constants' javadoc.
>  - Implement review feedback from mlchung.
>  - Fix type in @throws tag.
>  - Merge branch 'master' into JDK-8266670
>  - Respond to review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - Make workding changes suggested in review feedback.
>  - Merge branch 'master' into JDK-8266670
>  - ... and 22 more: https://git.openjdk.java.net/jdk/compare/74cd2687...05cf2d8b

src/java.base/share/classes/java/lang/reflect/Member.java line 96:

> 94:      */
> 95:     public default Set<AccessFlag> accessFlags() {
> 96:         return Set.of();

Is is not better to throw a NoSuchMethodError instead of Set.of() if there is no implementation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7445

From mchung at openjdk.java.net  Tue May 31 17:36:41 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 31 May 2022 17:36:41 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <I6NZh4eZvMP3l1P-7RGh21Et0CcGwrBCc3co0rQRnRs=.dd4df743-4b15-4c7c-aaea-3c40481a31e4@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
 <I6NZh4eZvMP3l1P-7RGh21Et0CcGwrBCc3co0rQRnRs=.dd4df743-4b15-4c7c-aaea-3c40481a31e4@github.com>
Message-ID: <ClPq-XCZaaaMq1n_4aZexrINIcUZQIcDkzA000QfOnk=.7309d333-748f-4695-89ef-7de496e53d28@github.com>

On Tue, 31 May 2022 13:26:17 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this test update reviewed?
>> 
>> The ForceGC could be enhanced by using smaller wait/sleep time, and shared cleaner.
>> 
>> Thanks,
>> Xuelei
>
> test/lib/jdk/test/lib/util/ForceGC.java line 50:
> 
>> 48:             for (int i = 0; i < 100; i++) {
>> 49:                 System.gc();
>> 50:                 System.out.println("doIt() iter: " + iter + ", gc " + i);
> 
> Maybe the trace should be printed only if `(i % 10 == 0) && (iter % 100 == 0)` to avoid having too many traces in the log?

This log was added to help debugging some past issues.  With this change, the volume of this trace would not be that helpful.   I think we can remove this log at this time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8907

From mchung at openjdk.java.net  Tue May 31 17:44:51 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 31 May 2022 17:44:51 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
Message-ID: <lN4QFl4HnAUNNS_ZXEM9HYMqPW2gMZxIx68Fqv09X98=.ce26e20f-2274-4f85-804b-0feccae94f10@github.com>

On Thu, 26 May 2022 18:50:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this test update reviewed?
> 
> The ForceGC could be enhanced by using smaller wait/sleep time, and shared cleaner.
> 
> Thanks,
> Xuelei

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8907

From mchung at openjdk.java.net  Tue May 31 17:44:54 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 31 May 2022 17:44:54 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <mndJqriwXrVX13QgdOWq9OsSjJiGdwAJCfLUhL-U7_E=.afda7b54-610c-4dfe-b9c2-087f30087343@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
 <npvq80nMqrkEtqt8_hRwpH1rVhbaJShmnHWgvtcB7ts=.400df4e0-99c2-4663-b71a-e2fcf5db0e74@github.com>
 <mndJqriwXrVX13QgdOWq9OsSjJiGdwAJCfLUhL-U7_E=.afda7b54-610c-4dfe-b9c2-087f30087343@github.com>
Message-ID: <tbHRSnHBM9qnsx0-wtiF0KdFDVvU0pzynIV2utk58Aw=.468797be-4195-41fc-aeb0-b9aba8a53285@github.com>

On Thu, 26 May 2022 21:40:42 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Even using a Cleaner is a more overhead than necessary.
> I would have skipped the overhead of a cleaner and Atomic classes with something more self contained as a static method:

Hmm... one benefit of Cleaner is the ease of use to avoid the need of managing the reference queue.  If the performance of the Cleaner API is a concern, perhaps we should look into reducing its overhead?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8907

From xuelei at openjdk.java.net  Tue May 31 17:44:55 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 31 May 2022 17:44:55 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <mndJqriwXrVX13QgdOWq9OsSjJiGdwAJCfLUhL-U7_E=.afda7b54-610c-4dfe-b9c2-087f30087343@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
 <npvq80nMqrkEtqt8_hRwpH1rVhbaJShmnHWgvtcB7ts=.400df4e0-99c2-4663-b71a-e2fcf5db0e74@github.com>
 <mndJqriwXrVX13QgdOWq9OsSjJiGdwAJCfLUhL-U7_E=.afda7b54-610c-4dfe-b9c2-087f30087343@github.com>
Message-ID: <NjQrIfZilJIt2BUygcVX9E_IJPOA53t_HdyrF6VIHuw=.2c2c4360-5ca8-408f-81d9-3c7662f44104@github.com>

On Thu, 26 May 2022 21:40:42 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > Even using a Cleaner is a more overhead than necessary. I would have skipped the overhead of a cleaner and Atomic classes with something more self contained as a static method:
> 
> I agreed that the using of Cleaner is still heavy, but it may be acceptable as the code is for testing only. If a new static method is introduced, test cases using the current API would also need update so as to benefit from it. I was hesitate for test cases update as it may involve more evaluations (and risks). But let me check.

I evaluated the use of ForceGC (10+ use).  It looks like that the update should be straightforward for most of them.  Most testing should be placed in case I missed something.  I would like to file a new RFE and submit this PR, so that if something is wrong with new update, we could rollback to this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8907

From rehn at openjdk.java.net  Tue May 31 17:47:46 2022
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 31 May 2022 17:47:46 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
Message-ID: <LK6sxMWt24m7zJEIp4eaUQINqXOJVgFZIS_qm3ZeH8U=.c684b70a-b64d-48a3-8e73-a560b1765b45@github.com>

On Tue, 31 May 2022 15:39:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
>> 
>> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
>> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
>> 
>> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allowing linking without intrinsic stub, contributed-by: rehn

Looks good, tested zero, thanks!

-------------

Marked as reviewed by rehn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8939

From xuelei at openjdk.java.net  Tue May 31 17:48:42 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 31 May 2022 17:48:42 GMT
Subject: Integrated: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
Message-ID: <DwohhJ3HZUMWOhBplTAi2ME7ssa7RWWRauHfDI7f5X8=.b1e883c4-2d46-43fe-ae0f-c0e06a2bc114@github.com>

On Thu, 26 May 2022 18:50:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this test update reviewed?
> 
> The ForceGC could be enhanced by using smaller wait/sleep time, and shared cleaner.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

Changeset: d5b6c7bd
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d5b6c7bde1ae1ddcc9ad31b99480b67a913ff20a
Stats:     21 lines in 1 file changed: 8 ins; 1 del; 12 mod

8287384: Speed up jdk.test.lib.util.ForceGC

Reviewed-by: rriggs, bchristi, dfuchs, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8907

From naoto at openjdk.java.net  Tue May 31 17:53:10 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 31 May 2022 17:53:10 GMT
Subject: RFR: 8287340: Refactor old code using StringTokenizer in locale
 related code
Message-ID: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>

Refactoring some old code in locale providers. The test case data have also been modified due to:
- There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
- `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

-------------

Commit messages:
 - 8287340: Refactor old code using StringTokenizer in locale related code

Changes: https://git.openjdk.java.net/jdk/pull/8960/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8960&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287340
  Stats: 175 lines in 4 files changed: 6 ins; 61 del; 108 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8960.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8960/head:pull/8960

PR: https://git.openjdk.java.net/jdk/pull/8960

From rriggs at openjdk.java.net  Tue May 31 17:53:52 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 31 May 2022 17:53:52 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <tbHRSnHBM9qnsx0-wtiF0KdFDVvU0pzynIV2utk58Aw=.468797be-4195-41fc-aeb0-b9aba8a53285@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
 <npvq80nMqrkEtqt8_hRwpH1rVhbaJShmnHWgvtcB7ts=.400df4e0-99c2-4663-b71a-e2fcf5db0e74@github.com>
 <mndJqriwXrVX13QgdOWq9OsSjJiGdwAJCfLUhL-U7_E=.afda7b54-610c-4dfe-b9c2-087f30087343@github.com>
 <tbHRSnHBM9qnsx0-wtiF0KdFDVvU0pzynIV2utk58Aw=.468797be-4195-41fc-aeb0-b9aba8a53285@github.com>
Message-ID: <buNgUKdTn_zuG5NDDmIOhxVbYJ9Ge_tDiSw4Rem1bAQ=.bc84dbb9-2b8c-4243-9850-78b5df4251a8@github.com>

On Tue, 31 May 2022 17:41:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Hmm... one benefit of Cleaner is the ease of use to avoid the need of managing the reference queue. If the performance of the Cleaner API is a concern, perhaps we should look into reducing its overhead?

The code using a Cleaner here creates a CountDownLatch to wait on; that along with the Cleaner seems very similar to the complexity of the suggested alternative directly using a ReferenceQueue.  But I'm fine with it either way

Each Cleaner creates a new OS thread, used for a single instance of ForceGC.  
The caching of the Cleaner in a Static mostly reduces the per ForceGC overhead.

When Loom is a feature, a Virtual Thread would be sufficient.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8907

From xuelei at openjdk.java.net  Tue May 31 17:53:53 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 31 May 2022 17:53:53 GMT
Subject: RFR: 8287384: Speed up jdk.test.lib.util.ForceGC
In-Reply-To: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
References: <KJbuvocBNCUC6CyzklWBwC25ZKwWHQTX6CWsWn3pkgc=.2b46630a-11a5-4949-8977-b86b4817d89a@github.com>
Message-ID: <k6_lAfwICOTRMcNokSPFlklk-CB4PEI3Yla1d43kKwA=.f40a5af7-6868-4756-9876-bd9ff12e716c@github.com>

On Thu, 26 May 2022 18:50:07 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this test update reviewed?
> 
> The ForceGC could be enhanced by using smaller wait/sleep time, and shared cleaner.
> 
> Thanks,
> Xuelei

Sorry, I was working on a history webpage while submit the PR and did not notice new comments.  I will address the missed comments in the following up RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8907

From mchung at openjdk.java.net  Tue May 31 18:02:41 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 31 May 2022 18:02:41 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v3]
In-Reply-To: <l1sQtEvlaQYid5hChUR-LYIUQ1MmUReWBPcA-c3dmEY=.c23da7dd-7b17-4c42-b0d2-66bcbfe2ac48@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <EHoFyUMigGVOCBpQh4nyb3CVm-iRxiNquJGTkfJ0ei4=.fd2c8d1a-235b-44d0-a0a2-6027230a7964@github.com>
 <l1sQtEvlaQYid5hChUR-LYIUQ1MmUReWBPcA-c3dmEY=.c23da7dd-7b17-4c42-b0d2-66bcbfe2ac48@github.com>
Message-ID: <-pz5TC_Wwx7eDI2EPJY5NFP0migvoMHt8um2zaNR18E=.88720eb9-5b0e-4673-94d0-8c97de543ebc@github.com>

On Mon, 30 May 2022 05:37:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I don't think jdk/nullCaller is right location for this. Maybe jni/nullCaller could work. You'll probably need to add the location to an appropriate group/tier in test/jdk/TEST.groups, otherwise it won't be run.

I also think `test/jdk/jni/nullCaller` is better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8934

From mchung at openjdk.java.net  Tue May 31 18:02:45 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 31 May 2022 18:02:45 GMT
Subject: RFR: 8287171: Refactor null caller tests to a single directory
 [v3]
In-Reply-To: <EHoFyUMigGVOCBpQh4nyb3CVm-iRxiNquJGTkfJ0ei4=.fd2c8d1a-235b-44d0-a0a2-6027230a7964@github.com>
References: <6bzH7OtJnDEgejU6oQyq-CNlT94Nvv1ALnYOfzop-GE=.da43a236-2872-4ccd-bc55-f1638f6a2efc@github.com>
 <EHoFyUMigGVOCBpQh4nyb3CVm-iRxiNquJGTkfJ0ei4=.fd2c8d1a-235b-44d0-a0a2-6027230a7964@github.com>
Message-ID: <skHD6IriqQFbXhL8VsvdkBm04kfLDQnpDLSk7LmNBr4=.7746594f-eb24-457f-baa4-f2d27f92c1ec@github.com>

On Mon, 30 May 2022 00:10:50 GMT, Tim Prinzing <duke at openjdk.java.net> wrote:

>> Created a test at test/jdk/jdk/nullCaller called NullCallerTest that creates a test module with some resources in it for the actual tests that occur at the native level. The native part was switched to c++ instead of c to make it easier to create helper objects that reduce the redundant code performing error checking. The two helper classes InstanceCall and StaticCall were placed in an include file called CallHelper.hpp. The main part of the tests are in exeNullCallerTest.cpp, and there is a separate function for each of the bug reports.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   problem with iostream on Windows, use printf

test/jdk/jdk/nullCaller/CallHelper.hpp line 176:

> 174:     }
> 175: 
> 176:     // call an method returning an object checking for exceptions and

`s/an method/a method/`

test/jdk/jdk/nullCaller/exeNullCallerTest.cpp line 29:

> 27:  * ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame
> 28:  */
> 29: void JDK_8280902(JNIEnv* env) {

A descriptive method name would be more helpful than the bug ID, for example, `getResourceBundle` and `registerClassLoaderAsParallelCapable`

test/jdk/jdk/nullCaller/exeNullCallerTest.cpp line 49:

> 47: 
> 48:     // check the message
> 49:     if (std::string("Hello!") != env->GetStringUTFChars(msg,NULL)) {

nit: a space after the comma `(msg, NULL)` consistent with the format in this local file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8934

From duke at openjdk.java.net  Tue May 31 18:31:44 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 31 May 2022 18:31:44 GMT
Subject: Integrated: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo
In-Reply-To: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
References: <0inJWpK7YkSjvzOT6sbnyzrVqnPW1Kz6nvFubsx-RKE=.bcc41464-0ed3-44c5-b2cc-ca00eb42b959@github.com>
Message-ID: <ygfRBlMIeDqJ8j6EqH0jTpmnfeE4smJ6B1XETnjCiO4=.533b3a27-4be4-4fda-9091-9e42d4e9f8ec@github.com>

On Fri, 20 May 2022 04:55:37 GMT, liach <duke at openjdk.java.net> wrote:

> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace the hash map with a simple lookup, similar to what's done in [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)

This pull request has now been integrated.

Changeset: 37a51300
Author:    liach <liach at users.noreply.github.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/37a513003c654297d81fc71b64c604f0ab8075cb
Stats:     86 lines in 1 file changed: 19 ins; 39 del; 28 mod

8287064: Modernize ProxyGenerator.PrimitiveTypeInfo

Reviewed-by: rriggs, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8801

From duke at openjdk.java.net  Tue May 31 18:34:44 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 31 May 2022 18:34:44 GMT
Subject: Integrated: 8285401: Proxy class initializer should use 3-arg
 `Class.forName` to avoid unnecessary class initialization
In-Reply-To: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
References: <VWjks5XPKU5VcfJd4y5uqUKDFA3_5MOzzft3UaFUPn0=.44f6641e-0e1f-42fa-b0e7-dae55382b49d@github.com>
Message-ID: <khHASztGwXSfTtWO8V-ryxa3jvxJ2KiKW7Uu1n5Ka9s=.f37cd4b5-518d-4bfe-9830-70225c876df1@github.com>

On Fri, 20 May 2022 03:50:58 GMT, liach <duke at openjdk.java.net> wrote:

> Simplify calls `Class.forName(String, boolean, ClassLoader)` instead of `Class.forName(String)`. `make test TEST="jtreg:test/jdk/java/lang/reflect/Proxy"` passes, with the new `LazyInitializationTest` failing the eager initialization check on the baseline and passing with this patch.
> 
> On a side note, this might reduce the number of methods that can be encoded in a proxy due to code attribute size restrictions; we probably would address that in another issue, as we never mandated a count of methods that the proxy must be able to implement.
> 
> Mandy, would you mind review this?

This pull request has now been integrated.

Changeset: e0382c55
Author:    liach <liach at users.noreply.github.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e0382c552348d108e906792ad8ca7067f9f805ec
Stats:     76 lines in 2 files changed: 72 ins; 0 del; 4 mod

8285401: Proxy class initializer should use 3-arg `Class.forName` to avoid unnecessary class initialization

Reviewed-by: rriggs, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/8800

From duke at openjdk.java.net  Tue May 31 19:21:31 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 31 May 2022 19:21:31 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v3]
In-Reply-To: <YVQ7GMQ03C5cZYKAEGSHD5mgsHdlA2bvsUnf_BZh50o=.e1ff3297-199e-46a3-944b-3d921868d8db@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <OStgY1PdPJqJiSG70ARRKrbtijHMbcvzKVgT-__RE0Q=.4f65f935-1da4-428b-8cbb-4540728138f4@github.com>
 <YVQ7GMQ03C5cZYKAEGSHD5mgsHdlA2bvsUnf_BZh50o=.e1ff3297-199e-46a3-944b-3d921868d8db@github.com>
Message-ID: <I3n8KJdXlosZB34JrhH8C4g60KYJws_e8ztU1XxGyaY=.4c9a5d8e-522f-46e8-8a41-dcd30bd4852d@github.com>

On Fri, 20 May 2022 00:10:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> liach 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:
>> 
>>  - Updates suggested by mandy
>>  - Merge branch 'master' into fix/proxy-single-pass
>>  - Don't need to complexify module cache
>>  - 8284942: Proxy building can just iterate superinterfaces once
>
> Looks good with a couple comments.

@mlchung Would you review again that I've updated per your suggestions? In addition, I've moved all proxy class context-related validation into the record compact constructor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From duke at openjdk.java.net  Tue May 31 19:30:07 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 31 May 2022 19:30:07 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v8]
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <Y7WjcHhnNeuHZERo6xvUsI_aK84wsMqJos07I-Tmqa8=.b13f68ef-e4bd-4aca-922f-6cd3e31c327f@github.com>

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - 8282662: Revert wrong copyright year change
 - 8282662: Revert ProxyGenerator
 - 8282662: Revert ProxyGenerator
 - 8282662: Revert dubious changes in MethodType
 - 8282662: Revert dubious changes
 - 8282662: Use List/Set.of() factory methods to save memory

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7729/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=07
  Stats: 13 lines in 5 files changed: 1 ins; 2 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7729.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729

PR: https://git.openjdk.java.net/jdk/pull/7729

From rriggs at openjdk.java.net  Tue May 31 19:36:44 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 31 May 2022 19:36:44 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v8]
In-Reply-To: <Y7WjcHhnNeuHZERo6xvUsI_aK84wsMqJos07I-Tmqa8=.b13f68ef-e4bd-4aca-922f-6cd3e31c327f@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <Y7WjcHhnNeuHZERo6xvUsI_aK84wsMqJos07I-Tmqa8=.b13f68ef-e4bd-4aca-922f-6cd3e31c327f@github.com>
Message-ID: <oo2f4d-qNFdBD7pLV8cX75QbJ3x4iyltEKddk-9TFx4=.e13529ee-4eea-460a-bab3-c02c38f21fb5@github.com>

On Tue, 31 May 2022 19:30:07 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - 8282662: Revert wrong copyright year change
>  - 8282662: Revert ProxyGenerator
>  - 8282662: Revert ProxyGenerator
>  - 8282662: Revert dubious changes in MethodType
>  - 8282662: Revert dubious changes
>  - 8282662: Use List/Set.of() factory methods to save memory

Why the force push?  They are discouraged, making it harder to review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From mchung at openjdk.java.net  Tue May 31 19:37:43 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 31 May 2022 19:37:43 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v6]
In-Reply-To: <qdr4XR_9GE7BC8eklkGUMN35XhC0ZOxfAyFLY44eCb4=.d5b30f63-1770-4e10-9764-bc786b2e258b@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <qdr4XR_9GE7BC8eklkGUMN35XhC0ZOxfAyFLY44eCb4=.d5b30f63-1770-4e10-9764-bc786b2e258b@github.com>
Message-ID: <tiqPhvZ69Lui0pXTlpflGHYjKdHk0Y3vAF1q1Av5F60=.f09f80ad-11b0-4bf4-83ad-a715310433ea@github.com>

On Thu, 26 May 2022 23:20:27 GMT, liach <duke at openjdk.java.net> wrote:

>> Currently, in ProxyBuilder::mapToModule and ProxyBuilder::defineProxyClass, the interfaces are iterated twice. The two passes can be merged into one, yielding the whole proxy definition context (module, package, whether there's package-private interface) when determining the module.
>> 
>> Split from #8278. Helpful for moving proxies to hidden classes, but is a good cleanup on its own.
>
> liach has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes suggested by mandy

Looks good.  Thanks.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8281

From duke at openjdk.java.net  Tue May 31 19:46:26 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 31 May 2022 19:46:26 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v4]
In-Reply-To: <Pc26qPovgWchtLlJWnCCx7tv1i0uhgQYmNji-aJylEA=.6dd31410-f275-479d-8073-8f333d8a5035@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <UCmcIC38gTHOC4h24nU36xV973FAPzOYVeN5UEKGt7E=.80b8b023-b3cd-4fa6-8833-5c12b59e45d9@github.com>
 <Pc26qPovgWchtLlJWnCCx7tv1i0uhgQYmNji-aJylEA=.6dd31410-f275-479d-8073-8f333d8a5035@github.com>
Message-ID: <jspH6WnJON5xkpsAYuivROO0QwdF9b6ycA3KWSj3R20=.2bc3d355-1a33-4bc8-9e9e-2aab5dfc0364@github.com>

On Tue, 31 May 2022 17:21:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
>>  - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
>
> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 67:
> 
>> 65:         if ((month > Month.MARCH.getValue() && month < Month.OCTOBER.getValue()) ||
>> 66:                 (month == Month.MARCH.getValue() && date.isAfter(getLastSundayOfMonth(date))) ||
>> 67:                 (month == Month.OCTOBER.getValue() && date.isBefore(getLastSundayOfMonth(date)))) {
> 
> I don't think these conditions are correct, as `month` is zero-based, and comparing it with `Month.MARCH` will be incorrect. The same holds for October.

Oh thats true, just verified this by printing out the values. Will fix by adding 1 to the month for sensible direct comparison against the singleton instances.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From iris at openjdk.java.net  Tue May 31 20:09:33 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 31 May 2022 20:09:33 GMT
Subject: RFR: 8287340: Refactor old code using StringTokenizer in locale
 related code
In-Reply-To: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
References: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
Message-ID: <x8XUZxX619B1RyUF0y3WMdsRg1XFJ4NvU7ZkxcG-TDw=.fc860b7d-93a0-46eb-90f8-e497e9f964e1@github.com>

On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactoring some old code in locale providers. The test case data have also been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

Very nice code moderization.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8960

From duke at openjdk.java.net  Tue May 31 20:10:44 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 31 May 2022 20:10:44 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v5]
In-Reply-To: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
Message-ID: <7SpDwS0sWsYuaiBdJqhhqUPEyc7gcBcL4mExUW3RE_4=.a62ad8f9-7fe9-4d45-92b9-74222698e845@github.com>

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:

  8285838: Corrected month comparison check for TZ DST

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/d7831659..9e3b1bb4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=03-04

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8661/head:pull/8661

PR: https://git.openjdk.java.net/jdk/pull/8661

From duke at openjdk.java.net  Tue May 31 20:31:04 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 31 May 2022 20:31:04 GMT
Subject: RFR: 8284942: Proxy building can just iterate superinterfaces once
 [v6]
In-Reply-To: <tiqPhvZ69Lui0pXTlpflGHYjKdHk0Y3vAF1q1Av5F60=.f09f80ad-11b0-4bf4-83ad-a715310433ea@github.com>
References: <2lVF2V3BXkTIQXTkoy0mfpIVDL97LzzbhLLvU-piask=.095aab45-7cd8-44f6-9edb-51a23ce4bcd1@github.com>
 <qdr4XR_9GE7BC8eklkGUMN35XhC0ZOxfAyFLY44eCb4=.d5b30f63-1770-4e10-9764-bc786b2e258b@github.com>
 <tiqPhvZ69Lui0pXTlpflGHYjKdHk0Y3vAF1q1Av5F60=.f09f80ad-11b0-4bf4-83ad-a715310433ea@github.com>
Message-ID: <XFjN31CAcBsE81YvBHxAAJN_gguTsi1hgcA0jMbs8jU=.b3e2dd0c-b35a-48cc-b99b-e5413b1f3853@github.com>

On Tue, 31 May 2022 19:33:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> liach has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixes suggested by mandy
>
> Looks good.  Thanks.

@mlchung Would you mind sponsoring this patch?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8281

From darcy at openjdk.java.net  Tue May 31 20:32:13 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 31 May 2022 20:32:13 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3]
In-Reply-To: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
Message-ID: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>

> Time to start getting ready for JDK 20...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:

 - Update deprecated options test.
 - Merge branch 'master' into JDK-8284858
 - Respond to review feedback.
 - Update symbol information for JDK 19 b24.
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Merge branch 'master' into JDK-8284858
 - Update symbol information for JDK 19 b23.
 - ... and 26 more: https://git.openjdk.java.net/jdk/compare/57d97d36...eedd36bd

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8236/files
  - new: https://git.openjdk.java.net/jdk/pull/8236/files/96be1787..eedd36bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8236&range=01-02

  Stats: 41686 lines in 344 files changed: 18832 ins; 17644 del; 5210 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8236.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236

PR: https://git.openjdk.java.net/jdk/pull/8236

From joehw at openjdk.java.net  Tue May 31 20:44:36 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 31 May 2022 20:44:36 GMT
Subject: RFR: 8287340: Refactor old code using StringTokenizer in locale
 related code
In-Reply-To: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
References: <qWF5tUAU0UOsEa-UcmbVFpcwjExl7f5BoRTUCgYQj5A=.8b944316-fc9d-40c6-bfce-5960bab8b01a@github.com>
Message-ID: <q_JK8dYRd4__Av-hFMZBS5vxsCdTtTaZGKcoAUuxtis=.eea37c53-7d9b-4de1-8f39-18427b4249ce@github.com>

On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Refactoring some old code in locale providers. The test case data have also been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8960

From duke at openjdk.java.net  Tue May 31 21:01:59 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 31 May 2022 21:01:59 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v8]
In-Reply-To: <oo2f4d-qNFdBD7pLV8cX75QbJ3x4iyltEKddk-9TFx4=.e13529ee-4eea-460a-bab3-c02c38f21fb5@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <Y7WjcHhnNeuHZERo6xvUsI_aK84wsMqJos07I-Tmqa8=.b13f68ef-e4bd-4aca-922f-6cd3e31c327f@github.com>
 <oo2f4d-qNFdBD7pLV8cX75QbJ3x4iyltEKddk-9TFx4=.e13529ee-4eea-460a-bab3-c02c38f21fb5@github.com>
Message-ID: <An9b7wEyg8S0U5RLnMjrPXHoXH9yMQEVLeZr8JhtXCE=.1e3365ab-29b4-4095-ae78-d941207f48ba@github.com>

On Tue, 31 May 2022 19:33:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ?????? ??????? 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 six additional commits since the last revision:
>> 
>>  - 8282662: Revert wrong copyright year change
>>  - 8282662: Revert ProxyGenerator
>>  - 8282662: Revert ProxyGenerator
>>  - 8282662: Revert dubious changes in MethodType
>>  - 8282662: Revert dubious changes
>>  - 8282662: Use List/Set.of() factory methods to save memory
>
> Why the force push?  They are discouraged, making it harder to review.

@RogerRiggs I've rebased my changes onto master to incorporate the latest changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From rriggs at openjdk.java.net  Tue May 31 21:07:50 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 31 May 2022 21:07:50 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v8]
In-Reply-To: <Y7WjcHhnNeuHZERo6xvUsI_aK84wsMqJos07I-Tmqa8=.b13f68ef-e4bd-4aca-922f-6cd3e31c327f@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <Y7WjcHhnNeuHZERo6xvUsI_aK84wsMqJos07I-Tmqa8=.b13f68ef-e4bd-4aca-922f-6cd3e31c327f@github.com>
Message-ID: <qKRXp9c2H3OfjraIw1b-mbHhPhcVklbL-uG0UI7WLEI=.141bb87f-3c74-4f22-b545-f0adb7756018@github.com>

On Tue, 31 May 2022 19:30:07 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - 8282662: Revert wrong copyright year change
>  - 8282662: Revert ProxyGenerator
>  - 8282662: Revert ProxyGenerator
>  - 8282662: Revert dubious changes in MethodType
>  - 8282662: Revert dubious changes
>  - 8282662: Use List/Set.of() factory methods to save memory

Merging is preferable, it doesn't disturb the history.
Usually an explicit merge is not necessary; Skara will indicate when an automatic merge is needed due to conflicts.
If you want to run your own tests then use a merge, not rebase.
Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/7729

From aturbanov at openjdk.java.net  Tue May 31 21:11:42 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 31 May 2022 21:11:42 GMT
Subject: Integrated: 8287544: Replace uses of StringBuffer with StringBuilder
 in java.naming
In-Reply-To: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
References: <pYAwrc6pr3jwhKtx1jnI8CRpRVWeRig3BriH5_7dw1I=.18d7ccfa-ee6e-47c1-88e3-61e5df4e6b8f@github.com>
Message-ID: <erm6Vl0SDlbo6iZtucQ3GSHdT-xojEDb1vDPeDnlemo=.5569315e-355f-4edf-87d9-fe1625dd9dbf@github.com>

On Sun, 29 May 2022 21:57:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
> There are some code that still uses StringBuffer in java.naming which could be migrated to `StringBuilder`.

This pull request has now been integrated.

Changeset: f5bbade9
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f5bbade9e40ed99d53d50c828d672b4eaab35018
Stats:     9 lines in 2 files changed: 0 ins; 0 del; 9 mod

8287544: Replace uses of StringBuffer with StringBuilder in java.naming

Reviewed-by: rriggs, aefimov, vtewari

-------------

PR: https://git.openjdk.java.net/jdk/pull/8942

From smarks at openjdk.java.net  Tue May 31 21:29:47 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 31 May 2022 21:29:47 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <hUNdKd0hg15wmWCKpJe5Rb6l07eny_fpjMLX6wFHJgE=.fcba18af-9e5f-4686-a0e4-0042d1a70673@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Reviewers, could I get a review for CSR [JDK-8287419](https://bugs.openjdk.java.net/browse/JDK-8287419) please? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8302

From bpb at openjdk.java.net  Tue May 31 21:39:43 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 31 May 2022 21:39:43 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
Message-ID: <YyvIu3-afX0JFoKQMqGXf74FJx215KbHhjtlHavxiAE=.89870ec2-2706-47ff-aa3d-b4b5a2fb7331@github.com>

On Tue, 31 May 2022 17:07:06 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

src/java.base/share/classes/jdk/internal/math/MathUtils.java line 38:

> 36:      *
> 37:      *     Giulietti, "The Schubfach way to render doubles",
> 38:      *     https://drive.google.com/file/d/1gp5xv4CAa78SVgCeWfGqqI4FfYYYuNFb

Even though not public, should the reference use the `<cite/>` tag and perhaps be in a `@see` annotation?

@see <a href=?https://drive.google.com/file/d/1gp5xv4CAa78SVgCeWfGqqI4FfYYYuNFb?>
     <cite>The Schubfach way to render doubles</cite></a>

src/java.base/share/classes/jdk/internal/math/MathUtils.java line 193:

> 191:      */
> 192:     private static final long[] g = {
> 193:         /* -324 */ 0x4F0C_EDC9_5A71_8DD4L, 0x5B01_E8B0_9AA0_D1B5L,

Not significant, but might this be clearer instead to comment the array elements on the right?

    0x4F0C_EDC9_5A71_8DD4L, 0x5B01_E8B0_9AA0_D1B5L, // -324

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From iris at openjdk.java.net  Tue May 31 21:47:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 31 May 2022 21:47:40 GMT
Subject: RFR: JDK-8284858: Start of release updates for JDK 20 [v3]
In-Reply-To: <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>
References: <OerQfYjuYaTUNVK_zfar2VMk8And9-Su9GJCqxkKfvw=.2b459bd5-cce3-4efa-ba4f-e9c0db7c2b10@github.com>
 <6jNbvqpG9h3UaeXfoS-E3E83XWEHgxobxKm2GWeaxJA=.aba8eef4-b036-46f7-9a6c-e668c80f5aac@github.com>
Message-ID: <h9kns6pddZvzfAYdA1SIDbMZRZfWOoS3P09wkSGqC6o=.5cae6eb9-2a20-4d7f-a703-c77fb94dfdab@github.com>

On Tue, 31 May 2022 20:32:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to start getting ready for JDK 20...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:
> 
>  - Update deprecated options test.
>  - Merge branch 'master' into JDK-8284858
>  - Respond to review feedback.
>  - Update symbol information for JDK 19 b24.
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Merge branch 'master' into JDK-8284858
>  - Update symbol information for JDK 19 b23.
>  - ... and 26 more: https://git.openjdk.java.net/jdk/compare/d01d01b5...eedd36bd

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8236

From bpb at openjdk.java.net  Tue May 31 21:54:51 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 31 May 2022 21:54:51 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
Message-ID: <yTG4Dw5HwPReMqFZ5rpqWJkU_4BDkUTEhOt_Yeu05-Y=.ce50e34f-39a2-476f-aeec-29672e9d94f8@github.com>

On Tue, 31 May 2022 17:07:06 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 47:

> 45:      * [2] IEEE Computer Society, "IEEE Standard for Floating-Point Arithmetic"
> 46:      *
> 47:      * [3] Bouvier & Zimmermann, "Division-Free Binary-to-Decimal Conversion"

Similar comment concerning `<cite/>` tag as in `MathUtils`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From bpb at openjdk.java.net  Tue May 31 21:59:58 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 31 May 2022 21:59:58 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
Message-ID: <zaMLwUfbx_2XOvCd8FDgi6CSd73nfpoFwVbV7yOKgy4=.88f95354-f376-484e-9ae4-391513c1d913@github.com>

On Tue, 31 May 2022 17:07:06 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 97:

> 95:     private static final int MASK_28 = (1 << 28) - 1;
> 96: 
> 97:     private static final int NON_SPECIAL    = 0;

Would these constants be better as an enum?

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 118:

> 116:     private int index;
> 117: 
> 118:     private DoubleToDecimal() {

Maybe add a comment like

    /**
     * Prevent instantiation.
     */

or

// Prevent instantiation of this class.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From bpb at openjdk.java.net  Tue May 31 22:15:38 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 31 May 2022 22:15:38 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
Message-ID: <mncUCyJ9LgMIQWmh6du5CpXX2M3OrXzlocDfE1yQAQs=.46da3a2f-14c7-41b7-96f6-9601a397b662@github.com>

On Tue, 31 May 2022 17:07:06 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java line 40:

> 38: final public class FloatToDecimal {
> 39:     /*
> 40:      * For full details about this code see the following references:

Same comment about `<cite/>`.

src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java line 97:

> 95:     private static final int MASK_28 = (1 << 28) - 1;
> 96: 
> 97:     private static final int NON_SPECIAL    = 0;

As these are shared with `DoubleToDecimal` would these constants be better moved to a common location, e.g., `MathUtils` whether converted to an `enum` or not?

src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java line 118:

> 116:     private int index;
> 117: 
> 118:     private FloatToDecimal() {

Same comment about preventing instantiation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From duke at openjdk.java.net  Tue May 31 22:27:32 2022
From: duke at openjdk.java.net (liach)
Date: Tue, 31 May 2022 22:27:32 GMT
Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for
 values everywhere except remove(K,V) and replace(K,V,V)
In-Reply-To: <9HfZ30vnoRR_s3cMkzToyj1ZV-0GXQFcBeoqua8gcM4=.775c0a7a-a38c-403f-948c-b584c89e10ee@github.com>
References: <fc2XirljYJd6OFW15qD9lTU_3ObG963GlTO-sVKGBg4=.946021e6-66fc-4473-9b37-2b3913e4fea4@github.com>
 <9HfZ30vnoRR_s3cMkzToyj1ZV-0GXQFcBeoqua8gcM4=.775c0a7a-a38c-403f-948c-b584c89e10ee@github.com>
Message-ID: <T0RI1U2wtS-hSfpNAIn7RxMmd_qSWmLb2wnSYBQLCK4=.3957f6a6-f823-41e2-bf3b-ebd27b1c3f93@github.com>

On Thu, 21 Apr 2022 00:48:00 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior.
>
> Thanks for working on this. Yes I can review and sponsor this change.
> 
> Sorry I got a bit distracted. I started looking at the test here, and this lead me to inquire about what other tests we have for `IdentityHashMap`, and the answer is: not enough. See [JDK-8285295](https://bugs.openjdk.java.net/browse/JDK-8285295). (But that should be handled separately.)

@stuart-marks Just curious, would this fix target 19 or 20 at the current state?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8259

From bpb at openjdk.java.net  Tue May 31 22:29:54 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 31 May 2022 22:29:54 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect
 results [v14]
In-Reply-To: <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <MLwHRA-Y2Tl7eJ0LbgmnuUZgYPkjGNsQMhKsbZ-pneU=.a0d0cd71-9cca-4826-b337-3b7a835f8eaa@github.com>
Message-ID: <wnuLttkARp76bYylH3DvI7lhiQPCfBfiy_rQXcfTCnc=.026c9cb7-3bd5-4cc6-a376-cfb1491fe13b@github.com>

On Tue, 31 May 2022 17:07:06 GMT, Raffaello Giulietti <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 72:

> 70:     static final int E_MAX = 309;
> 71: 
> 72:     /* Threshold to detect tiny values, as in section 8.2.1 of [1] */

Comments like this one pointing to specific places in the Schubfach paper are very helpful in understanding the constants and the various steps in the algorithm.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3402

From naoto at openjdk.java.net  Tue May 31 22:37:52 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 31 May 2022 22:37:52 GMT
Subject: RFR: 8285838: DST not applying properly with zone id offset set
 with TZ env variable [v5]
In-Reply-To: <7SpDwS0sWsYuaiBdJqhhqUPEyc7gcBcL4mExUW3RE_4=.a62ad8f9-7fe9-4d45-92b9-74222698e845@github.com>
References: <su-wGDMIAtLMmtXYYp3x4vb5W4G32YFB0uAv5OYO17E=.590ea8c6-2098-4567-b21a-0b96b73ba9b2@github.com>
 <7SpDwS0sWsYuaiBdJqhhqUPEyc7gcBcL4mExUW3RE_4=.a62ad8f9-7fe9-4d45-92b9-74222698e845@github.com>
Message-ID: <dbQFYDugzX8zNINu-4WJ6fAoSoTAdXa72GqkqKuBCCQ=.28a3eb2a-4d60-4dac-bc84-f0386dfad30f@github.com>

On Tue, 31 May 2022 20:10:44 GMT, Gaurav Chaudhari <duke at openjdk.java.net> wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285838: Corrected month comparison check for TZ DST

I tried out your patch on my local Linux machine, but the new test failed with the following exception:

ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]
REASON: User specified action: run main/othervm CustomTzIDCheckDST 
TIME:   1.564 seconds
messages:
command: main CustomTzIDCheckDST
reason: User specified action: run main/othervm CustomTzIDCheckDST 
Mode: othervm [/othervm specified]
elapsed time (seconds): 1.564
configuration:
STDOUT:
Command line: [/home/nsato/projects/jdk/git/jdk/build/linux-x64/images/jdk/bin/java -cp /home/nsato/projects/jdk/git/jdk/build/linux-x64/test-support/jtreg_open_test_jdk_java_util_TimeZone/classes/0/java/util/TimeZone/CustomTzIDCheckDST.d:/home/nsato/projects/jdk/git/jdk/open/test/jdk/java/util/TimeZone:/home/nsato/projects/jdk/git/jdk/build/linux-x64/test-support/jtreg_open_test_jdk_java_util_TimeZone/classes/0/test/lib:/home/nsato/projects/jdk/git/jdk/open/test/lib:/var/tmp/jib-nsato/install/jtreg/6.1/1/bundles/jtreg-6.1+1.zip/jtreg/lib/javatest.jar:/var/tmp/jib-nsato/install/jtreg/6.1/1/bundles/jtreg-6.1+1.zip/jtreg/lib/jtreg.jar CustomTzIDCheckDST runTZTest ]
[2022-05-31T22:27:05.958567816Z] Gathering output for process 14771
[2022-05-31T22:27:06.635595481Z] Waiting for completion for process 14771
[2022-05-31T22:27:06.635976964Z] Waiting for completion finished for process 14771
Output and diagnostic info for process 14771 was saved into 'pid-14771-output.log'
[2022-05-31T22:27:06.663087767Z] Waiting for completion for process 14771
[2022-05-31T22:27:06.663360403Z] Waiting for completion finished for process 14771
[2022-05-31T22:27:06.663754609Z] Waiting for completion for process 14771
[2022-05-31T22:27:06.663869034Z] Waiting for completion finished for process 14771
STDERR:
 stdout: [];
 stderr: [Exception in thread "main" java.time.DateTimeException: Invalid ID for offset-based ZoneId: GMT-22:00
	at java.base/java.time.ZoneId.ofWithPrefix(ZoneId.java:436)
	at java.base/java.time.ZoneId.of(ZoneId.java:406)
	at java.base/java.time.ZoneId.of(ZoneId.java:358)
	at java.base/java.time.ZoneId.of(ZoneId.java:314)
	at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:581)
	at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
	at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:570)
	at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
	at java.base/java.time.ZoneId.systemDefault(ZoneId.java:274)
	at CustomTzIDCheckDST.runTZTest(CustomTzIDCheckDST.java:64)
	at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:51)
Caused by: java.time.DateTimeException: Zone offset hours not in valid range: value -22 is not in the range -18 to 18
	at java.base/java.time.ZoneOffset.validate(ZoneOffset.java:373)
	at java.base/java.time.ZoneOffset.ofHoursMinutesSeconds(ZoneOffset.java:326)
	at java.base/java.time.ZoneOffset.of(ZoneOffset.java:257)
	at java.base/java.time.ZoneId.ofWithPrefix(ZoneId.java:430)
	... 10 more
]
 exitValue = 1

java.lang.RuntimeException: Expected to get exit value of [0]

	at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:489)
	at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:49)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:1585)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to get exit value of [0]

JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From mchung at openjdk.java.net  Tue May 31 23:48:34 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 31 May 2022 23:48:34 GMT
Subject: RFR: 8287496: Alternative virtual thread implementation that maps
 to OS thread [v2]
In-Reply-To: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
References: <y5jBtTX-JtoWklQl8EMXcxb-K3OwzNZzsLAbcTpiyxA=.74dd0edf-292a-4f0e-9ddf-b665cc13f5e9@github.com>
 <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com>
Message-ID: <C36rgf1exkAzaEnvT8kTwv8-UDyp1_5ttKtWbJcLQGc=.136015c1-ef9d-4470-9422-02a2e46a099c@github.com>

On Tue, 31 May 2022 15:39:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means:
>> 
>> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 
>> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI)
>> 
>> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allowing linking without intrinsic stub, contributed-by: rehn

Looks okay to me.

src/java.management/share/classes/sun/management/ThreadImpl.java line 586:

> 584: 
> 585:     /**
> 586:      * Returns the ThreadInfo objects from the given array that coresspond to platform

typo: coresspond -> correspond

src/java.management/share/classes/sun/management/Util.java line 92:

> 90: 
> 91:     /**
> 92:      * Returns true if the given Thread is a virutal thread.

typo: virutal -> virtual

this typo appears in other comments too.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8939